The Naz.API Credential Stuffing List
troyhunt.com
troyhunt.com
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.
Edit: I know at least 1Password and Bitwarden do that for you.
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?
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.
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 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.
Can you see if my passwd is in there ***?*
So basically: did that DB grow from about 27 GB to 37 GB in the last few days?
The urls are https://api.pwnedpasswords.com/range/00000 to .../FFFFF, downloadable via any http client.
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.
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.
% head -1 | tr -d \\n | shasum
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.
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/
> 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.
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 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.
Google: "leak-name-here download"
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...).
I want to know which service (https://www.troyhunt.com/content/images/2024/01/image.png) my details were linked with.
The compromised password can and should be deleted by them, and ignored by us.
[1] https://www.troyhunt.com/the-111-million-pemiblanc-credentia...
Subscribe 1password Donate.
- 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 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.
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.
& 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
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 :)
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.
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.
How strong is that nowadays? How many bits of entropy?
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.
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.
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.)
We get about 5 emails a year at work through these services, as we don't have a "delete account" button.
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.
And I am also on the nas.api list.
https://www.cvedetails.com/vulnerability-list/vendor_id-1196...
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.
> 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
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
(1gbps is 450GB/hour, useful for estimating things)
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.
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.
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.
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?
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).
EDIT: How to register your spare Yubikey: https://support.yubico.com/hc/en-us/articles/360021919459
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?
The concept that if I lose my key I am totally screwed doesn’t align.
Notary public... the new digital locksmith for password recovery.
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.
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'.
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.
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.