[HN Gopher] The Naz.API Credential Stuffing List
___________________________________________________________________
The Naz.API Credential Stuffing List
Author : AdmiralAsshat
Score : 90 points
Date : 2024-01-17 14:27 UTC (1 days ago)
(HTM) web link (www.troyhunt.com)
(TXT) w3m dump (www.troyhunt.com)
| derwiki wrote:
| 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?
| mdrzn wrote:
| 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?
| derwiki wrote:
| 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.
| damacus wrote:
| I'm hoping 1password's watch tower will shortly help.
| jgimenez wrote:
| 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.
| derwiki wrote:
| 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
| cpv wrote:
| Would be safer to just change your passwords. If they are old,
| even better to change them right now.
| 00deadbeef wrote:
| 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.
| devrand wrote:
| 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.
| 00deadbeef wrote:
| That's also useful as it might lead to clues to
| identifying a potentially compromised machine
| fr3nzy4x wrote:
| 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
| mdeeks wrote:
| 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?
| DANmode wrote:
| Understanding which of your accounts is valuable, and which
| isn't, is a worthwhile task in itself.
| AdmiralAsshat wrote:
| 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.
| muskypirate wrote:
| 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
| tourmalinetaco wrote:
| 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.
| mdrzn wrote:
| 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."
| twisteriffic wrote:
| 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.
| 00deadbeef wrote:
| 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.
| haswell wrote:
| 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.
| 00deadbeef wrote:
| 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.
| willcipriano wrote:
| 00deadbeef@gmail.com is in the leak-name-here leak!
|
| Google: "leak-name-here download"
| dwild wrote:
| 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...).
| 00deadbeef wrote:
| No I don't mean download the dump.
|
| I want to know which service (https://www.troyhunt.com/co
| ntent/images/2024/01/image.png) my details were linked
| with.
| Shorel wrote:
| 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.
| MertsA wrote:
| 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.
| DylanSp wrote:
| 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...
| tggm wrote:
| Actually there are two actions possible on the
| notification/HIBP website/blog:
|
| Subscribe 1password Donate.
| silent_kyblik wrote:
| Looks like Seagate NAS software, see
| https://www.reddit.com/r/computerviruses/comments/189e0j9/co...
| Demonsult wrote:
| Interesting. I'm in the breach but never knowingly used that
| software, so it's likely buried under some other product or
| service.
| silent_kyblik wrote:
| Me neither, all I had was Western Digital MyCloud NAS years
| ago, but nothing from Seagate
| great_psy wrote:
| I also had a western digital nas that got bricked by a
| software update.
|
| And I am also on the nas.api list.
| upon_drumhead wrote:
| I'm relatively certain I never used that software with the
| email that showed up on the breach warning :(
| toomuchtodo wrote:
| > 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...
| 00deadbeef wrote:
| 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.
| pfak wrote:
| 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.
| AdmiralAsshat wrote:
| 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.
| devrand wrote:
| 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
| tegrq wrote:
| 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?
| CBossy wrote:
| 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.
| templeosenjoyer wrote:
| 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.
| charcircuit wrote:
| Searching it is timing out for me, but if this works it would
| be much more effective to know what actually leaked.
| templeosenjoyer wrote:
| 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.
| miyakoyako wrote:
| 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.
| jve wrote:
| 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.
| fr3nzy4x wrote:
| 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)
| infinitusJM wrote:
| 7 records for me that relate to two old data breeches - Dropbox
| and Last FM.
| lelanthran wrote:
| 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.
| phpisthebest wrote:
| You can download the password hashes.
|
| https://haveibeenpwned.com/Passwords
| hennell wrote:
| They have a downloader for the hashed password list:
| https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader
| diggan wrote:
| Any ideas what the final size on disk would be after
| downloading?
| oldprogrammer2 wrote:
| It is 37 GB (I downloaded it yesterday).
| samstave wrote:
| Obligatory H2:
|
| _Can you see if my passwd is in there ***_?*
| bookofjoe wrote:
| Asking for a friend
| denysvitali wrote:
| Looks like hunter2 to me
| TacticalCoder wrote:
| 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?
| thesuitonym wrote:
| Why does this need to be an app? Why not just release the
| hashes?
| CodesInChaos wrote:
| 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.
| nighthawk454 wrote:
| Thanks, TIL! Bet JDownloader can make quick work of that
| as well
| rad_gruchalski wrote:
| You can just host it yourself:
| https://github.com/radekg/hibp.
| justinclift wrote:
| It's a .NET application, so may be windows only. :/
| jimbobimbo wrote:
| .NET 6+ is cross platform.
| justinclift wrote:
| Isn't that just specific parts, rather than the whole
| thing?
| daveoc64 wrote:
| 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.
| jjulius wrote:
| As mentioned in the article, the database has been uploaded
| with emails redacted to Troy's Pwned Password search on
| haveibeenpwned.
| fritzo wrote:
| They should offer a small Bloom filter for download.
| andrewla wrote:
| It's easy to check through their verification service if your
| passwords have been compromised.
|
| Hash your password locally $ echo -n
| fredflinstone | shasum
| 95e47d937e105fa1cc84bfa476b10f091304c090 -
|
| Then take the first five characters of the hash and invoke the
| API $ curl
| https://api.pwnedpasswords.com/range/95e47 ...
| D8F3BA8D3952AA8917C78295EE1122F675C:17
| D910D224A8450006478ED28D2CE2D005343:10
| D91C102088F1D91469B803235DB60903259:874
| D937E105FA1CC84BFA476B10F091304C090:290
| D96BF2796784C142392D8B46AEF68B991D0:4
| D98009835A90E46EFFD43AC3E5C6BD1C14B:5
|
| 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.
| sambazi wrote:
| add two spaces right before the echo to avoid logging your
| secrets in the shell history
| andrewla wrote:
| Or better, just do a `(read -s asdf; echo -n $asdf |
| shasum)` to create a temporary subshell and never even
| expose your password in the shell output.
| mzs wrote:
| % head -1 | tr -d \\n | shasum
|
| Type your username and press the RETURN key.
| freitzkriesler2 wrote:
| 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.
| diggan wrote:
| > 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 :)
| CoastalCoder wrote:
| 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.
| r1ch wrote:
| 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.
| andreareina wrote:
| HTTPS fixes that
| djbusby wrote:
| My password tool shows me which are oldest. So, quarterly (on
| tax day) I also make sure to change a few of them.
| avidiax wrote:
| 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.
| stcredzero wrote:
| _Nobody is spending a year to crack your passwords or use a
| leaked password_
|
| How strong is that nowadays? How many bits of entropy?
| notwhereyouare wrote:
| they may not, but if there is a password dump, you password
| isn't super old and has been rotated fairly recently
| djbusby wrote:
| 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.
| stcredzero wrote:
| _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.)
| Glant wrote:
| 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
| Symbiote wrote:
| 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.
| Arrath wrote:
| > 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.
| fr3nzy4x wrote:
| 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/
| fr3nzy4x wrote:
| 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
| TacticalCoder wrote:
| 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
| aaronax wrote:
| It is only tens of gigabytes, no need for fiber to handle this.
| The 37GB of files can be downloaded in 1 hour on an 83mbps
| link.
|
| (1gbps is 450GB/hour, useful for estimating things)
| myself248 wrote:
| My favorite rule of thumb is that 100Mbps is about 1TB/day.
| tylerchr wrote:
| 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
| andrewla wrote:
| 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
| ttul wrote:
| 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.
| jl2718 wrote:
| 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?
| laeri wrote:
| 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).
| nosefurhairdo wrote:
| Bitwarden + 2 yubikeys is my solution. I remember one
| password, keep one key with me, and leave one key at home.
| bloopernova wrote:
| 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
| alwa wrote:
| 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?
| ubercow13 wrote:
| Having the QR in your photo roll doesn't break the 'not
| phishable' property.
| the_pwner224 wrote:
| 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.
| zrail wrote:
| 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.
| the_pwner224 wrote:
| 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.
| pixl97 wrote:
| Dear sir, what is a locksmith, and why is there so many
| of them?
| dstroot wrote:
| 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.
| Nick87633 wrote:
| 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.
| Arrath wrote:
| 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.
| dataflow wrote:
| 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.
| mewpmewp2 wrote:
| And regular people also frequently lose their keys and
| cards, including me.
| hospitalJail wrote:
| 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'.
| verisimi wrote:
| Great list!
| smolder wrote:
| 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.
| xg15 wrote:
| 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.
| Too wrote:
| 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.
| rrobukef wrote:
| 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.
| mindslight wrote:
| 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.
| aimor wrote:
| 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.
| verisimi wrote:
| You trust your browser?
| maxwellg wrote:
| 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.
| xg15 wrote:
| 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.
| rad_gruchalski wrote:
| What sort of hashing algorithm do you use?
| username135 wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-18 23:00 UTC)