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.
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.
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)
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?
Yea, I thought about that too. I know there are some sketchy websites that provide paid access to leaks, but I was hoping for a course of action that is more legitimate.
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.
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
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.
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.
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 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.
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?
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.
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
And there we have it -- my password is compromised (the suffix D937...)
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.
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.
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/
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 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."
> 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.
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.
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.
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...).
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.
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
but fundamentally still leaves users vulnerable compared to other approaches. For example, client-side hashed passwords can still be phished, and are not domain-bound like Passkeys are.
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 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
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.
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.
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.
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.
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.)
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.
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.
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.
> 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
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'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.
> 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 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.
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.
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.
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 **
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.
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).
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?
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.
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.
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.
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.
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.
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.
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'.
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.
