The Naz.API Credential Stuffing List(troyhunt.com)
troyhunt.com
The Naz.API Credential Stuffing List
https://www.troyhunt.com/inside-the-massive-naz-api-credential-stuffing-list/
153 comments
The leaked dataset Troy refers to wasn't the real Naz.API list, and the "illicit.services" website Troy says is defunct is actually online at https://search.0t.rocks/. You can use this to see if you're in the real Naz.API dataset (which is way scarier than the data shared on breachforums). Those who are particularly interested can abuse the wildcards for search to scrape passwords associated with some email/username and create their own Naz.API "mirror" (as far as I know, there are only a handful of people with access to this dataset), though the rate-limiting may prove to be an irritating obstacle. The site owner may find issue with this too, as it certainly wasn't intentional, but when I tried it a few months back it worked perfectly.
0t creator here. Please do not scrape it! If you have a specific request for data (i.e. data from your business), look around for the riseup email on the announcements channel and contact from a DKIM validated company email address.
Is this for Naz.API data or all leaks?
Because I see entries for twitter/bittorent/Collection1 which HIBP already informed me years ago. So either Naz.API is aggregate of leaks with new or not new info or 0t provides data from various leaks.
Because I see entries for twitter/bittorent/Collection1 which HIBP already informed me years ago. So either Naz.API is aggregate of leaks with new or not new info or 0t provides data from various leaks.
All leaks. 0t is a collection of many leaks not just naz.api
im pretty sure that Naz.api is just a collection of new and old breaches and stealer logs because my data that was in Naz.api is the same as the data that was leaked in the polish credentials data breach (im not even polish idk why im in this)
Searching it is timing out for me, but if this works it would be much more effective to know what actually leaked.
Ha, it was working fine moments before I posted the comment, times out for me now too. Try revisiting later on, it definitely works great. From what I remember it was essentially created as a "fuck you" to Peter Kleissner, the creator of https://intelx.io/, who charges exorbitant prices to search breaches.
Even though I use a different password for each service, I have no idea which service's password was compromised because my "main" gmail was included in this breach. Do I need to use https://haveibeenpwned.com/Passwords to manually test each password I have saved with that email?
I have the same issue, I have no idea WHICH password has been affected.
Do I need to track down the original leak and search for my email?
try your email with https://search.0t.rocks/ I checked mine and it did pop the Naz.API leak showing the first and last character of your password. Mine was leaked from Netflix
Has there ever been a Netflix breach (on public record anyway)? I'd be more wary that your machine was infected, from my experience naz.api logs are mostly from infected machines.
Which is a weird thing to see. I used Netflix on Apple TV or on a mac. The likelihood of a malware on the latter is low but nonetheless it was an old pass from few years back and I have stopped Netflix subscription long ago.
Yes, you can use that or you can use the API. Some password managers are integrated with the API so they will do that for you.
Edit: I know at least 1Password and Bitwarden do that for you.
Edit: I know at least 1Password and Bitwarden do that for you.
1Password’s Watch Tower doesn’t show anything related to this breach, which might indicate it’s a super old password from pre-2011 that I’ve already deprecated
This is one of a few reasons I have started to use email forwarders such as AnonAddy.
https://github.com/anonaddy/anonaddy
Not all of my emails have been moved over yet, but over time I plan on depreciating almost if not all of my main emails from logins.
https://github.com/anonaddy/anonaddy
Not all of my emails have been moved over yet, but over time I plan on depreciating almost if not all of my main emails from logins.
The majority of my accounts are through a custom domain with a different username for each service. But that also means I don't have HIBP alerts set up for any of them.
I have the same setup by the sound of it and set up HIBP to let me know whenever any email using my domain appears in the database.
Same here. I call them canary email addresses when I have to describe it to someone, so I can tell when that organization loses its data.
For those of us crazy enough to do this, I came up with another type of canary, a "Do they check for compromised passwords?" canary. I have an old password that used to be strong enough for sites I considered low value and was too lazy to break out the password safe. Of course at least one of those low value sites was compromised and that password was leaked.
Now some of the services are high value to others while they remain low value to me. So they have enabled MFA and notifications when someone logs in. Since no one knows the email address I'm using and I've turned on MFA, I feel safe enough leaving that old compromised password in place. I'm waiting for the day they force me to reset it because they bothered to check their customer's existing passwords against compromised ones.
For those of us crazy enough to do this, I came up with another type of canary, a "Do they check for compromised passwords?" canary. I have an old password that used to be strong enough for sites I considered low value and was too lazy to break out the password safe. Of course at least one of those low value sites was compromised and that password was leaked.
Now some of the services are high value to others while they remain low value to me. So they have enabled MFA and notifications when someone logs in. Since no one knows the email address I'm using and I've turned on MFA, I feel safe enough leaving that old compromised password in place. I'm waiting for the day they force me to reset it because they bothered to check their customer's existing passwords against compromised ones.
I just did, since I only had less than 15 accounts associated with that email, and no hits reported. So either his Password search isn't loaded up yet with the latest breach, or whatever was in that breach was an old password that I've already rotated.
Some of my passwords weren’t found on that tool but I was able to find them on but scatteredsecrets.com - I searched because I was getting 2fa emails from services with that password. Just keep in mind it isn’t a definitive list
I love that password breaches are so common that everyone is perfectly fine just typing all their passwords into various sites.
I feel there ought to be some much-more-secure option, but it probably involves a level of client-side computation that the average person won't do on their own.
A good password vault should do that automatically for keys you have registered in it.
Would be safer to just change your passwords. If they are old, even better to change them right now.
I have 388 items in my password manager. 138 of them use my email address which was found in this breach :(
Not that you're wrong, but there is no reasonable way to rotate all of those. I guess I'll have to spend a few hours manually going through the ones I care about and rotating them?
Not that you're wrong, but there is no reasonable way to rotate all of those. I guess I'll have to spend a few hours manually going through the ones I care about and rotating them?
Understanding which of your accounts is valuable, and which isn't, is a worthwhile task in itself.
Is that the point? People want to know the source. I have rights under the GDPR that companies should be treating my data securely. I want to know who was compromised.
This particular dataset appears to have been collected by malware. So it wasn't a breached company, it was malware on some machine that impacted users used that logged usernames/passwords.
That's also useful as it might lead to clues to identifying a potentially compromised machine
I think the same malware that had breached my data awhile ago "Polish Credentials" is apart of this because the same old user:pass pairs so maybe its a bunch of data from multiple breaches if you were in the polish breach it dumped your google saved passwords so that would be whats affected
The HIBP database really should be open to the world, with the email being redacted.
I would love to grep the list of 25m passwords to see if any of mine are in there.
I don't particularly want to send my details to HIBP to check if I have been compromised.
I would love to grep the list of 25m passwords to see if any of mine are in there.
I don't particularly want to send my details to HIBP to check if I have been compromised.
It's easy to check through their verification service if your passwords have been compromised.
Hash your password locally
Easy enough to script this up with minimal information leakage. All you're sending is 20 bits; that's not enough to do anything malicious even if your password is compromised.
Hash your password locally
$ echo -n fredflinstone | shasum
95e47d937e105fa1cc84bfa476b10f091304c090 -
$ curl https://api.pwnedpasswords.com/range/95e47
...
D8F3BA8D3952AA8917C78295EE1122F675C:17
D910D224A8450006478ED28D2CE2D005343:10
D91C102088F1D91469B803235DB60903259:874
D937E105FA1CC84BFA476B10F091304C090:290
D96BF2796784C142392D8B46AEF68B991D0:4
D98009835A90E46EFFD43AC3E5C6BD1C14B:5
Easy enough to script this up with minimal information leakage. All you're sending is 20 bits; that's not enough to do anything malicious even if your password is compromised.
add two spaces right before the echo to avoid logging your secrets in the shell history
One space is sufficient in bash, if memory serves right.
And secondly, on macOS with the default config for zsh no amount of spaces will help, I think. You have to first configure zsh to ignore from history when starting with space. And after that I think one space will be enough.
And secondly, on macOS with the default config for zsh no amount of spaces will help, I think. You have to first configure zsh to ignore from history when starting with space. And after that I think one space will be enough.
That functionality in bash is controlled by the HISTCONTROL environment variable. Many systems this defaults to "ignorespace" but this isn't always the case.
On Fedora, with bash, HISTCONTROL defaults to "ignoredups" and is set by /etc/profile (unless it's changed in the last few years).
Usually you can set/unset the shell option "history". For instance, "set +o history" to disable history in the current shell and "set -o history" to turn it back on.
Edit, Looks like on Ubuntu HISTCONTROL=ignoreboth comes from .bashrc in /etc/skel/
On Fedora, with bash, HISTCONTROL defaults to "ignoredups" and is set by /etc/profile (unless it's changed in the last few years).
Usually you can set/unset the shell option "history". For instance, "set +o history" to disable history in the current shell and "set -o history" to turn it back on.
Edit, Looks like on Ubuntu HISTCONTROL=ignoreboth comes from .bashrc in /etc/skel/
thanks for the context
% head -1 | tr -d \\n | shasum
This could be baked into BitWarden to be honest. Or is it already? Yeah it seems it's there already https://github.com/bitwarden/clients/issues/523
Prefix not suffix
They have a downloader for the hashed password list:
https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader
Why does this need to be an app? Why not just release the hashes?
The hashes are split into a million (2^20) files based on the first 20 bits (5 hex characters) of the hash. The downloader is just a convenient way to download them all.
The urls are https://api.pwnedpasswords.com/range/00000 to .../FFFFF, downloadable via any http client.
The urls are https://api.pwnedpasswords.com/range/00000 to .../FFFFF, downloadable via any http client.
Thanks, TIL! Bet JDownloader can make quick work of that as well
You can just host it yourself: https://github.com/radekg/hibp.
[deleted]
Any ideas what the final size on disk would be after downloading?
It is 37 GB (I downloaded it yesterday).
Is it 37 GB with these new 1/3rd of previously unknown passwords hashes added?
So basically: did that DB grow from about 27 GB to 37 GB in the last few days?
So basically: did that DB grow from about 27 GB to 37 GB in the last few days?
Obligatory H2:
Can you see if my passwd is in there ***?*
Can you see if my passwd is in there ***?*
Looks like hunter2 to me
Asking for a friend
It's a .NET application, so may be windows only. :/
.NET 6+ is cross platform.
Isn't that just specific parts, rather than the whole thing?
The core of the .NET runtime is cross-platform.
You do have the option to use platform-specific APIs or frameworks, which will make your app only work on that platform.
In the case of this app, it doesn't use anything platform-specific, so it could run on Windows, Linux and macOS.
You do have the option to use platform-specific APIs or frameworks, which will make your app only work on that platform.
In the case of this app, it doesn't use anything platform-specific, so it could run on Windows, Linux and macOS.
You can download the password hashes.
https://haveibeenpwned.com/Passwords
https://haveibeenpwned.com/Passwords
As mentioned in the article, the database has been uploaded with emails redacted to Troy's Pwned Password search on haveibeenpwned.
[deleted]
They should offer a small Bloom filter for download.
The comments on Troy's website seems to agree with our general sentiment: "There is really nothing actionable with this notification. Would be nice to at least know which service(s) were associated with my email."
Troy's response:
> Think through what would mean: we’d have to sit on billions of plain text passwords (among other personal info) and return that visitors with no more validation than control of a single email address. The risk is huge, both to us and people in breaches.
His stance is reasonable.
> Think through what would mean: we’d have to sit on billions of plain text passwords (among other personal info) and return that visitors with no more validation than control of a single email address. The risk is huge, both to us and people in breaches.
His stance is reasonable.
I don't entirely agree it's reasonable. This dump apparently contains the source of the email+password combo. You can go on his website and look up sources of leaks with just an email address. That's what people really want to know: what was the source?
So yes sifting through billions of records will take a while, but it's possible, but telling the user the source of the details (and not the leaked passwords themselves) is exactly what his website mostly already does so it's not a risk.
So yes sifting through billions of records will take a while, but it's possible, but telling the user the source of the details (and not the leaked passwords themselves) is exactly what his website mostly already does so it's not a risk.
The risk is not in sifting through billions of records.
The risk is enabling a service that unlocks a capability like “give me the password for this email address that may or may not be mine”.
The source of a breach is a single attribute that can be associated with an entire dataset, unlike passwords.
The risk is enabling a service that unlocks a capability like “give me the password for this email address that may or may not be mine”.
The source of a breach is a single attribute that can be associated with an entire dataset, unlike passwords.
We only need to get the domain name of the service.
The compromised password can and should be deleted by them, and ignored by us.
The compromised password can and should be deleted by them, and ignored by us.
But I'm saying it should be possible to view the source of the password, not the password itself. Which is what his site already shows for individual breaches.
[email protected] is in the leak-name-here leak!
Google: "leak-name-here download"
Google: "leak-name-here download"
No I don't mean download the dump.
I want to know which service (https://www.troyhunt.com/content/images/2024/01/image.png) my details were linked with.
I want to know which service (https://www.troyhunt.com/content/images/2024/01/image.png) my details were linked with.
Are you saying that's the risk of providing the website URL? Or that it's the risk of the HIBP?
Because he does provide the email and the leak name... He even provide indirectly where to download it from his blogpost.
Providing the website won't give more dangerous information, that's exactly what he usually does when it's not a stuffing list, he say where the password come from (Linkedin, Facebook, etc...).
Because he does provide the email and the leak name... He even provide indirectly where to download it from his blogpost.
Providing the website won't give more dangerous information, that's exactly what he usually does when it's not a stuffing list, he say where the password come from (Linkedin, Facebook, etc...).
It's reasonable for displaying with nothing more than knowing the email on haveibeenpwned.com but for everyone subscribed to notifications it would have been very helpful to include the source in the notification email and that would have avoided the biggest part of the privacy implications. Right now for a lot of people the latest breach notification email is unactionable because there's no way to figure out what account may have been breached. For me personally I received the notification but when I checked the actual list directly, not only was it immediately clear that it wasn't an account I care about, it was also a password that I've used but never with the account listed. Had the email from HIBP included just a tiny bit of additional information I wouldn't have needed to waste my time on it, especially when it seems that this breach has some unknown amount of bogus data in it.
I'm not sure if the credential lists that HIBP pulls from always have the associated service/site. Looking up one of my emails, there's a mix of data breaches of specific sites (which are shown) and big lists of credentials, like the one in this blog post. The latter don't always have the associated source; the Pemiblanc list doesn't include the source, which is explicitly talked about in the associated blog post [1]. It'd be nice to display the source when possible, though.
[1] https://www.troyhunt.com/the-111-million-pemiblanc-credentia...
[1] https://www.troyhunt.com/the-111-million-pemiblanc-credentia...
Actually there are two actions possible on the notification/HIBP website/blog:
Subscribe 1password Donate.
Subscribe 1password Donate.
Why has authentication moved away from making passwords safer? I like to imagine a system where the only thing that ever sees my easy-to-remember password is the browser, everything downstream gets a unique client-side hash. We did this manually in the past with various schemes, we do this today with extra steps using password managers, why aren't browsers simplifying this? (or maybe they are?) My understanding is that these schemes (say, hash your password with the domain name) are vulnerable with enough samples, but it's still better than sending your easy-to-remember password out to the internet. The answers I hear online are that there's no value added since everyone should use unique passwords to begin with, but people don't do this because it's extra work even using a password manager is extra work, the default needs to be more secure.
My take on client-side hashing schemes is that they help with raising the floor -
- they ensure that the backend application never sees your password in plaintext , and prevent the worst case scenario of a plaintext data dump
- password hashing is CPU intensive by design, and pushing that work to the client means you can have them do the work and increase # of iterations far more aggressively
I think with the "X can be phished" argument, there is a massive tradeoff to keep in mind: Everything where you as a user have direct access to the key can in theory be phished. So the only way to make credentials unphishable is by hiding the key from yourself and entrusting it to a third party, in the way that passkeys work. However, now you're entirely dependant on that third party. The question is if, everything considered, this is really such a big security improvement for you.
I think an alternative approach would be to accept a certain risk that credentials can be stolen and improve the ways in which stolen credentials can be revoked.
I think an alternative approach would be to accept a certain risk that credentials can be stolen and improve the ways in which stolen credentials can be revoked.
What sort of hashing algorithm do you use?
I think this would complicate salting (making rainbow tables or brute force attacks easier). The client needs to know the salt so on a fresh device I think you're limited to
- using the username as a salt
- adding a second secret input field for the salt
- allowing the client to request a salt without authentication (which would verify the existence of an account)
& after trying to solve those problems, there's still mTLS or passkeys that offer better security anyways.
A password manager may be extra work but it's pretty minimal nowadays. On Chrome, it will automatically offer to generate passwords in signups and save them. If you add a Google, it will sync passwords between devices. Sure, everyone may not want this, but it's easy for less tech savvy people and still fairly secure
& after trying to solve those problems, there's still mTLS or passkeys that offer better security anyways.
A password manager may be extra work but it's pretty minimal nowadays. On Chrome, it will automatically offer to generate passwords in signups and save them. If you add a Google, it will sync passwords between devices. Sure, everyone may not want this, but it's easy for less tech savvy people and still fairly secure
If you want to log in from a different browser or device they need to agree on how this hashing works. This also means that everyone else knows how this hashing works and can construct rainbow tables for it.
Still better than plain text but nothing stopping a determined hacker.
Anything else is just encrypting the transport, which we already do with HTTPS.
Otherwise there is the ongoing work to of passkeys.
Still better than plain text but nothing stopping a determined hacker.
Anything else is just encrypting the transport, which we already do with HTTPS.
Otherwise there is the ongoing work to of passkeys.
Because 2fa lets password breaches be blamed on the user.
You trust your browser?
Ugh I have a smattering of accounts that use the same password before I wised up and started using a generator. My important accounts are secure by 2fa however and a strong password.
One day I'll sit down and just go through them all to fix them. Maybe just pay for wifi on a flight and clean it up.
One day I'll sit down and just go through them all to fix them. Maybe just pay for wifi on a flight and clean it up.
> One day I'll sit down and just go through them all to fix them. Maybe just pay for wifi on a flight and clean it up.
Maybe do it while being connected to a network that isn't infamous for its poor security :)
Maybe do it while being connected to a network that isn't infamous for its poor security :)
I'm not super educated on security stuff, but would airplane wifi add any significant risk?
I'd think that as long as your laptop isn't already compromised, and you don't need to use someone's proxy server, HTTPS would be secure enough. I.e., no worse than doing it from home.
I'd think that as long as your laptop isn't already compromised, and you don't need to use someone's proxy server, HTTPS would be secure enough. I.e., no worse than doing it from home.
The biggest risk is random mobile apps that disable HTTPS certificate checking, run APIs over plain HTTP, etc. On public Wi-Fi, anyone physically near you can intercept or snoop on that traffic.
Browsers generally do a good job of ensuring HTTPS these days, but still you should pay attention to make sure you're on HTTPS when using public Wi-Fi.
Browsers generally do a good job of ensuring HTTPS these days, but still you should pay attention to make sure you're on HTTPS when using public Wi-Fi.
HTTPS fixes that
One day I'll sit down and just go through them all to fix them.
I had a spate of going through and putting in 2FA on everything 1Password indicated could have it.
Then, I had another spate of changing all my passwords on accounts I still had in my defunct LastPass. (I switched from LastPass to 1Password before the big breach.)
I had a spate of going through and putting in 2FA on everything 1Password indicated could have it.
Then, I had another spate of changing all my passwords on accounts I still had in my defunct LastPass. (I switched from LastPass to 1Password before the big breach.)
You should try going through the list and deleting accounts you never use anymore. That one's always fun because many companies try to hide the delete account button or simply don't have one
There are services that do this by using GDPR rights. I think they scan email for "Welcome" emails, then automate the account deletion as far as possible.
We get about 5 emails a year at work through these services, as we don't have a "delete account" button.
We get about 5 emails a year at work through these services, as we don't have a "delete account" button.
My password tool shows me which are oldest. So, quarterly (on tax day) I also make sure to change a few of them.
What's the theory? Nobody is spending a year to crack your passwords or use a leaked password, so either they are strong enough to resist online or offline attacks, or they aren't. If they aren't strong enough, then you would have to rotate much more often than every few years.
Theory is that I'll rotate out passwords insecure? systems.
One case I know is that in one system my old password was hashed with an older method (which was the right choice at the time) and when I reset I'm now using their updated (right choice today) hash.
Another feature is that services I don't use I'm reminded to close/deactivate.
One case I know is that in one system my old password was hashed with an older method (which was the right choice at the time) and when I reset I'm now using their updated (right choice today) hash.
Another feature is that services I don't use I'm reminded to close/deactivate.
Assuming we start from the position of having a unique, never-before-seen password for each account (which is what we should all be doing, right?), rotating doesn't do anything.
And if we accept that most people don't use unique, never-before-seen passwords and that a password has been included in a plaintext dump, rotating passwords periodically doesn't even protect from password spray attacks, since someone has likely used that password before and you'll still be vulnerable.
And if we accept that most people don't use unique, never-before-seen passwords and that a password has been included in a plaintext dump, rotating passwords periodically doesn't even protect from password spray attacks, since someone has likely used that password before and you'll still be vulnerable.
Nobody is spending a year to crack your passwords or use a leaked password
How strong is that nowadays? How many bits of entropy?
How strong is that nowadays? How many bits of entropy?
they may not, but if there is a password dump, you password isn't super old and has been rotated fairly recently
> One day I'll sit down and just go through them all to fix them.
I like to tell this to myself every time I log onto my online banking using the 'Temporary <credit union name>' entry in bitwarden.
One day.
I like to tell this to myself every time I log onto my online banking using the 'Temporary <credit union name>' entry in bitwarden.
One day.
Looks like Seagate NAS software, see https://www.reddit.com/r/computerviruses/comments/189e0j9/co...
> Edit: Fount it. It’s a Seagate NAS operating system. As in Network Attached Storage. NAS.api is their API. So I think someone(s) was using Seagate NAS equipment and the API was insecure. Appears that Seagate is to blame for making an API that has some vulnerabilities
https://www.cvedetails.com/vulnerability-list/vendor_id-1196...
https://www.cvedetails.com/vulnerability-list/vendor_id-1196...
I got the email from HIBP but I've only ever owned one Seagate SATA HDD, never any of their NAS products, nothing cloud connected from them at all. This must be more than just Seagate.
I got an email from HIBP and I have a seagate.com account, but not their NAS. I filed a warranty claim once with them.
Interesting. I'm in the breach but never knowingly used that software, so it's likely buried under some other product or service.
I’m relatively certain I never used that software with the email that showed up on the breach warning :(
Me neither, all I had was Western Digital MyCloud NAS years ago, but nothing from Seagate
I also had a western digital nas that got bricked by a software update.
And I am also on the nas.api list.
And I am also on the nas.api list.
I've definitely never had a Seagate NAS before, but my email was in the breach.
Quite annoying, because it's my personal gmail which I rarely ever use to sign up for anything. Given that I maybe only have 15-20 accounts tied to that email, I wonder if I should just cycle through each password through HaveIBeenPwned's service.
Quite annoying, because it's my personal gmail which I rarely ever use to sign up for anything. Given that I maybe only have 15-20 accounts tied to that email, I wonder if I should just cycle through each password through HaveIBeenPwned's service.
Troy seems to disagree in the linked blog post:
> That last number was the real kicker; when a third of the email addresses have never been seen before, that's statistically significant. This isn't just the usual collection of repurposed lists wrapped up with a brand-new bow on it and passed off as the next big thing; it's a significant volume of new data. When you look at the above forum post the data accompanied, the reason why becomes clear: it's from "stealer logs" or in other words, malware that has grabbed credentials from compromised machines. Apparently, this was sourced from the now defunct illicit.services website which (in)famously provided search results for other people's data along these lines
> That last number was the real kicker; when a third of the email addresses have never been seen before, that's statistically significant. This isn't just the usual collection of repurposed lists wrapped up with a brand-new bow on it and passed off as the next big thing; it's a significant volume of new data. When you look at the above forum post the data accompanied, the reason why becomes clear: it's from "stealer logs" or in other words, malware that has grabbed credentials from compromised machines. Apparently, this was sourced from the now defunct illicit.services website which (in)famously provided search results for other people's data along these lines
Anybody runs the HIBP password DB locally? (ideally with this latest treasure trove) I saw some converted it to a Bloom filter (which makes lots of sense: for all the passwords on which it answers 'definitely not in set', you know there's no false positive and in case it'd answer 'potentially in set' you could still query manually against the online DB).
I'll search online but if a fellow HNer runs it offline, I'm all ears...
P.S: I've got Gbit/s FTTH as well as servers in datacenters so downloading tens of gigabytes ain't an issue
I'll search online but if a fellow HNer runs it offline, I'm all ears...
P.S: I've got Gbit/s FTTH as well as servers in datacenters so downloading tens of gigabytes ain't an issue
I wrote a thing for this back when you could download the whole hash database as a single torrent, but I haven’t checked it since they moved over to the PwnedPasswordsDownloader system. This doesn’t use any probabilistic data structures though, it just packs the database into the smallest binary file I could come up with.
https://github.com/tylerchr/pwnedpass
https://github.com/tylerchr/pwnedpass
I have a project which acts as a local cache for the HIBP database.
https://github.com/lorenz/hibp-cached
It downloads and continually updates from the upstream database while serving the identical API. On a fast link it can download the entire thing in a few hours.
It just uses a giant BoltDB file to store compressed chunks.
https://github.com/lorenz/hibp-cached
It downloads and continually updates from the upstream database while serving the identical API. On a fast link it can download the entire thing in a few hours.
It just uses a giant BoltDB file to store compressed chunks.
Curious about your use case; using their online service [1] is up-to-date and reveals almost no information.
[1] https://news.ycombinator.com/item?id=39044339
[1] https://news.ycombinator.com/item?id=39044339
[deleted]
I had received an email from haveibeenpwned yesterday and just got into looking into this after reading through literally every comment on this forum im thinking that this is a breach that covers over a bunch of other breaches the "Polish Credentials" Data breach is the only other one ive been in and the password associated with that is the only one that appears to be in a breach and my new one has yet to come back as breached im not even from poland but was still compromised in that breach due to malware that was trying to blackmail me with somthing they didnt have and if you want to see what password was taken with the new breach use https://search.0t.rocks/
also the screenshot in Troy Hunts post shows an account on the craxpro hacking website which i do have a account on with a temp password so if its that site breached i would check that out
SO apparently one of my emails is in the list and it seems to be some type of seagate service thing. The thing is, i do not remember at all of using any seagate services ever in my life time so how that can be?
On a positive note, I am seeing more sites offering Passkeys, which integrate natively with browsers and provide vastly superior security compared with passwords.
We won’t ever eliminate the human error that leads to password theft. At least Passkey offers a way for your computer to securely authenticate a web site and for them to authenticate you in a way that cannot be stolen by a third party, because the credential doesn’t exist in a part of your computer that can be read by local programs.
We won’t ever eliminate the human error that leads to password theft. At least Passkey offers a way for your computer to securely authenticate a web site and for them to authenticate you in a way that cannot be stolen by a third party, because the credential doesn’t exist in a part of your computer that can be read by local programs.
ametrau(2)
Keepass + cloud drive for storage.
Easiest, safest solution, imo. Your very own personal database of passwords for everything. Takes a bit to set up but once your done, you're done.
I believe they even use this at nasa/jpl.
Easiest, safest solution, imo. Your very own personal database of passwords for everything. Takes a bit to set up but once your done, you're done.
I believe they even use this at nasa/jpl.
I received an email from TotalAV telling me my details were included in a Naz.api data breach. I'm not sure I've ever used Seagate for anything.
how do you view the *** password as text? It shows my account appeared in the hack any the password was p**k I don’t remember ever using a password with P and K, curious how I can view what is being the **
7 records for me that relate to two old data breeches - Dropbox and Last FM.
Let’s recap the problem:
Passwords don’t work because people can’t remember very much. Password generators don’t work because they have to store the key somewhere. Might as well just authenticate with the encryption key. Encryption keys often get lost, so they need to be stored in the cloud, accessible with a password, which brings us back to the first problem, but adds another point of exploit, or ‘lawful intercept’. Phone number second factor doesn’t work because that can be stolen or transferred, and the same device is probably used for password reset. Authenticator apps don’t work because devices can be stolen, and they require a password anyway to transfer to a new device. Biometrics don’t work because they can be cloned, or used on an incapacitated person, and in the case of phone biometrics, they can be overridden with a pin. FiDO devices don’t work because they can be lost or stolen and used by someone else. Social recovery doesn’t work because of moral hazard and probably the only people you trust that much are not particularly savvy with security around this kind of thing. Practically in an app, they would also have to authenticate in some technical manner, so this cascades.
What have I missed?
Passwords don’t work because people can’t remember very much. Password generators don’t work because they have to store the key somewhere. Might as well just authenticate with the encryption key. Encryption keys often get lost, so they need to be stored in the cloud, accessible with a password, which brings us back to the first problem, but adds another point of exploit, or ‘lawful intercept’. Phone number second factor doesn’t work because that can be stolen or transferred, and the same device is probably used for password reset. Authenticator apps don’t work because devices can be stolen, and they require a password anyway to transfer to a new device. Biometrics don’t work because they can be cloned, or used on an incapacitated person, and in the case of phone biometrics, they can be overridden with a pin. FiDO devices don’t work because they can be lost or stolen and used by someone else. Social recovery doesn’t work because of moral hazard and probably the only people you trust that much are not particularly savvy with security around this kind of thing. Practically in an app, they would also have to authenticate in some technical manner, so this cascades.
What have I missed?
FIDO/physical keys still work and they are still the best solution. Sure they can be stolen but physical access is much harder to get than digital access. The loss problem is also practically not of importance as a backup key can mitigate this. Also physical loss does not guarantee access to the new owner as they need to know which identity uses the key as well as the password as the key is only the second factor.
Best solution would probably be an implant of the physical key which makes it nearly impossible to lose it (apart from the worst case scenario).
Best solution would probably be an implant of the physical key which makes it nearly impossible to lose it (apart from the worst case scenario).
Bitwarden + 2 yubikeys is my solution. I remember one password, keep one key with me, and leave one key at home.
Is there a "create duplicate/backup of yubikey" app of some kind?
EDIT: How to register your spare Yubikey: https://support.yubico.com/hc/en-us/articles/360021919459
EDIT: How to register your spare Yubikey: https://support.yubico.com/hc/en-us/articles/360021919459
Wait, they suggest saving photos of the QR codes of your TOTP secrets? That seems to weaken the concept by making it easy for an attacker 1) to identify secrets and the sites they’re associated with, and 2) to retrieve them (in plaintext, no less) with no more than access to a device’s photo roll.
I thought the idea was that we’d write the secret once to an arbitrary number of primary and backup devices, then destroy it so it can’t be stolen as easily. Although I guess password managers save TOTP secrets alongside the password factor these days too.
Does the “the secret itself is not phishable” aspect of TOTP just not actually matter in practice as much as the rapid expiration and frustrating replay attacks / on-the-wire sort of secret interception?
I thought the idea was that we’d write the secret once to an arbitrary number of primary and backup devices, then destroy it so it can’t be stolen as easily. Although I guess password managers save TOTP secrets alongside the password factor these days too.
Does the “the secret itself is not phishable” aspect of TOTP just not actually matter in practice as much as the rapid expiration and frustrating replay attacks / on-the-wire sort of secret interception?
Having the QR in your photo roll doesn't break the 'not phishable' property.
Regular people are incapable of properly managing a key + keeping an up to date backup. You still need to have a recovery mechanism for lost keys.
Regular people have been carrying house keys and/or car keys around for practically their entire lives. A physical key for their computers wouldn't be weird, except it's different than what they're used to.
Dear sir, what is a locksmith, and why is there so many of them?
This. People assume weak security. They think if they lose their house or car key they can get in some other way, or a locksmith can “fix it”, or they can order another car key at the dealer.
The concept that if I lose my key I am totally screwed doesn’t align.
The concept that if I lose my key I am totally screwed doesn’t align.
Case study: An Ex who got fully locked out of her phone by forgetting what new passcode she changed to, had no idea what her google account password was, either.
So in the end she was locked out of the encrypted backups and had to wipe the phone, losing photos and a lot of notes. Despite all this, somehow expected that a quick ring to the <Cell Provider> call center could get her files unlocked and restored. Once that proved fruitless, that a call to Google would do the trick.
So in the end she was locked out of the encrypted backups and had to wipe the phone, losing photos and a lot of notes. Despite all this, somehow expected that a quick ring to the <Cell Provider> call center could get her files unlocked and restored. Once that proved fruitless, that a call to Google would do the trick.
Car keys are getting a lot more troublesome these days. I see an analogy... if you lose your security device you can pay $XX to get on a call and verify with an account security rep. Of course this can be deepfaked nowadays. Maybe you need to do password recovery in person with a notary!
Notary public... the new digital locksmith for password recovery.
Notary public... the new digital locksmith for password recovery.
You don't need to regularly plug your spare house key into your computer to update the password DB on it. And even with spares people still get locked out and need locksmiths.
People already get locked out of their homes regularly. Imagine how much more frequently that would happen if they keychain also had a security key they had to take out regularly.
And regular people also frequently lose their keys and cards, including me.
I'd agree with the sibling comments that physical keys are probably still the best option, along maybe with the realisation that without some sort of trust root based on human contact, things don't work.
Case in point: we actually have an extremely widely used 2factor system which appears to be working reasonably well for several decades now, despite constant attacks and strong incentives to crack it: Debit cards, PINs and ATMs. Even with the constant threat of skimmers, there hasn't been any mass events of emptied bank accounts so far.
Why does it work? My hunch is that two factors play a role: 1) it's based on a physical token, so any attack is necessarily local and needs "people on the ground". 2) there is actually a robust system for recovery and revocation in the shape of bank branches that you can visit, which involve human staff who can apply common sense judgement. Those make the event of a lost card into a nuisance rather than catastrophe.
And maybe the second lesson we can learn from the breach: Entrusting the entire collection of passwords of your digital life to a single 3rd party and then allowing that party to upload the passwords to the cloud, in plaintext, does not just superficially appear to be a bad idea that is actually genius because of crypto magic, it is, in fact, a really bad idea.
Case in point: we actually have an extremely widely used 2factor system which appears to be working reasonably well for several decades now, despite constant attacks and strong incentives to crack it: Debit cards, PINs and ATMs. Even with the constant threat of skimmers, there hasn't been any mass events of emptied bank accounts so far.
Why does it work? My hunch is that two factors play a role: 1) it's based on a physical token, so any attack is necessarily local and needs "people on the ground". 2) there is actually a robust system for recovery and revocation in the shape of bank branches that you can visit, which involve human staff who can apply common sense judgement. Those make the event of a lost card into a nuisance rather than catastrophe.
And maybe the second lesson we can learn from the breach: Entrusting the entire collection of passwords of your digital life to a single 3rd party and then allowing that party to upload the passwords to the cloud, in plaintext, does not just superficially appear to be a bad idea that is actually genius because of crypto magic, it is, in fact, a really bad idea.
Passwords work to a point, with some effort. Perhaps people just need to expect a level of security that is proportional to their efforts. No free lunch, it's all trade-offs. For people who are not capable of managing it themselves, they will need help or risk ending up victims.
For lawful things that aren't targeted by major attackers, almost everything you said is fine.
For things that are high value or targeted by major attackers, you spend the extra effort on physical keys or a better authenticator system. I can think of a few methods that would make it quite difficult by adding multiple layers. A determined person with a gun might be able to get it, but even then, I have some 'traps'.
For things that are high value or targeted by major attackers, you spend the extra effort on physical keys or a better authenticator system. I can think of a few methods that would make it quite difficult by adding multiple layers. A determined person with a gun might be able to get it, but even then, I have some 'traps'.
This is why 2FA is so so important.
Something you have physically and something you remember. Doesn’t matter if one of them is weak or can be lost, the combination will be stronger than a single difficult password.
Something you have physically and something you remember. Doesn’t matter if one of them is weak or can be lost, the combination will be stronger than a single difficult password.
OIDC/oAuth seems like the solution: make it somebody else's problem. But OIDC tokens can be stolen, they can change domains because of misconfiguration or bad redirect urls.
You've missed that the ultimate problem is this assumption that there even exists one singular "best" way that should be implemented uniformly top-down. Some people will be happy using secure passwords and a local password manager. Others will be happy with no password but an email/SMS challenge. Some will prefer setting up a menagerie of security keys. Any many will prefer different mechanisms for different sites, depending on what a particular site means to them. Infantilizing people and trying to protect them in spite of themselves never works out, but rather just makes for a race to the bureaucratic bottom where everyone suffers death by a thousand paper cuts.
[deleted]
Great list!
[deleted]