Live data from Hacker News

What We Do in the /etc/shadow – Cryptography with Passwords

soatok.blog

11–20 of 34 posts

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#11
I notice the article stopped citing examples of large-scale password cracking after the introduction of PBKDF2.

Technical tours through the winding passages of password management in services is fun and all, but I wonder if this is ultimately contributing more to bad habits than good ones.

Readers capable of implementing something like OPAQUE will already have a pretty good handle on most of what's written here. All other developers will just grab whatever "the" off-the-shelf solution is for their language and tech stack, and any recommendations for those are conspicuously absent here. What are the best resources for the most popular tech stacks currently? PHP introduced the password_hash() function (and related functions) in its standard library a while back. It defaults to bcrypt, and most php devs should probably just use those functions, unless they're sure they know better.

There's another end of all this that I also never see addressed in writeups like this one: lots of users are still really bad at passwords. I still have a few friends that obsessively write passwords down on index cards and rotate the same weak passwords through all the services they use. I have installed password managers for them; I have walked through using password managers multiple times; I have explained the risks half a dozen times, with a different strategy each time. As the blogger says, "passwords suck". Ultimately people like this keep reusing crappy passwords everywhere because services don't prevent it, and in that case, it mostly doesn't matter which fancypants algorithm you go with for handling authentication.

For a while, some misguided sites tried to prevent people from pasting passwords into their login forms. I have never seen the inverse: a site that prevents users from typing a password. Is there a reason that wouldn't work? Because if it would, it would only take a few big services doing that to finally force the last holdouts to adopt password managers. And that, I think, would contribute a lot more to overall password security than trying to decide whether to use bcrypt, scrypt, pbkdf2, argon, or hokeypokey5.

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#12
post #9

Earlier quoted context omitted.

...that's a Cloudflare security page. Is this a default setting for one of Cloudflare's security options, or did Algolia specifically add this to some edge detection worker or something? I'm curious which party is being ridiculous.

I just hit a website I know has an entirely default config on the free plan as https://website/q=cat /etc/shadow and got the same exact error page.

Ohhh Cloudflare. I have to wonder how many sites are left that are actually vulnerable to having their shadow file dumped. Even for the sites that have filesystem traversal vulns, how many of those would cough up something publicly accessible from the shadow file?

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#13

I notice the article stopped citing examples of large-scale password cracking after the introduction of PBKDF2. Technical tours through the winding passages of password management in services is fun and all, but I wonder if this is ultimately contributing more to bad habits than good ones. Readers capable of implementing something like OPAQUE will already have a pretty good handle on most of what's written here. All…

> There's another end of all this that I also never see addressed in writeups like this one: lots of users are still really bad at passwords.

Author here.

I was originally planning to write a blog post about my experience reporting cryptography-related bugs to password managers in 2022. (I had findings for LastPass, 1Password, and Keeper.)

My experience with LastPass was abysmal. I wrote a thread about it here: https://furry.engineer/@soatok/109560736140669727

However, I found in my early draft that I spent a lot of time explaining these algorithms, so I decided to spin it off into a separate article. Thus, this post was conceived!

> I notice the article stopped citing examples of large-scale password cracking after the introduction of PBKDF2.

At that point, I figured the point had been made already, and wanted to focus on the algorithms.

> Readers capable of implementing something like OPAQUE will already have a pretty good handle on most of what's written here. All other developers will just grab whatever "the" off-the-shelf solution is for their language and tech stack, and any recommendations for those are conspicuously absent here. What are the best resources for the most popular tech stacks currently? PHP introduced the password_hash() function (and related functions) in its standard library a while back. It defaults to bcrypt, and most php devs should probably just use those functions, unless they're sure they know better.

I tried to make the post a good balance of fun and informative, but the audience was "people who want to know more about cryptography with passwords" not specifically developers.

As you indicated, if you're developing something, the password_hash() / password_verify() API your language provides is likely 1000x safer than rolling your own anything. If there is to be improvements in the cryptography for a given programming language, it should be an update to whatever the de facto standard library is for that language.

PHP has the password extension built-in. Python has passlib. Node has the crypto module. Etc.

> For a while, some misguided sites tried to prevent people from pasting passwords into their login forms. I have never seen the inverse: a site that prevents users from typing a password. Is there a reason that wouldn't work?

I'm not confident in this, since it's 4:46 AM for me and I should probably be sleeping instead of reading HN comments, but isn't this exactly how Passkey is supposed to work? I could be confusing it with another thing though.

Anyway, thanks for your insightful feedback. I already planned a teardown into the reverse-engineered internals of popular password managers and my experiences with them. Because of your comment, I might also make a future blog post targeting developers.

In the meantime, here's some cool stuff:

https://github.com/dropbox/zxcvbn - A reasonable approach to password strength estimation (although I think their calculation needs updating in 2023)

https://github.com/DivineOmega/password_exposed - Checks if a given password has been exposed in a previous breach (uses the HIBP hash database)

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#14

I notice the article stopped citing examples of large-scale password cracking after the introduction of PBKDF2. Technical tours through the winding passages of password management in services is fun and all, but I wonder if this is ultimately contributing more to bad habits than good ones. Readers capable of implementing something like OPAQUE will already have a pretty good handle on most of what's written here. All…

> There's another end of all this that I also never see addressed in writeups like this one: lots of users are still really bad at passwords. Author here. I was originally planning to write a blog post about my experience reporting cryptography-related bugs to password managers in 2022. (I had findings for LastPass, 1Password, and Keeper.) My experience with LastPass was abysmal. I wrote a thread about it here: https…

The bit about selling to the government isn't quite right. Check out NIST SP 800-63B §5.1.1.2. They're very keen on memory-hard functions, as long as the underlying primitives are approved. For some reason they single out Balloon, which I wouldn't recommend since there's only a prototype implementation, but scrypt and yescrypt are usable.

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#15

Earlier quoted context omitted.

> There's another end of all this that I also never see addressed in writeups like this one: lots of users are still really bad at passwords. Author here. I was originally planning to write a blog post about my experience reporting cryptography-related bugs to password managers in 2022. (I had findings for LastPass, 1Password, and Keeper.) My experience with LastPass was abysmal. I wrote a thread about it here: https…

The bit about selling to the government isn't quite right. Check out NIST SP 800-63B §5.1.1.2. They're very keen on memory-hard functions, as long as the underlying primitives are approved. For some reason they single out Balloon, which I wouldn't recommend since there's only a prototype implementation, but scrypt and yescrypt are usable.

Thanks. I'm not a FIPS expert, and I try to avoid having to become a FIPS expert, so I appreciate these corrections.

(I've updated the post to encapsulate your correction.)

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#16

I notice the article stopped citing examples of large-scale password cracking after the introduction of PBKDF2. Technical tours through the winding passages of password management in services is fun and all, but I wonder if this is ultimately contributing more to bad habits than good ones. Readers capable of implementing something like OPAQUE will already have a pretty good handle on most of what's written here. All…

> There's another end of all this that I also never see addressed in writeups like this one: lots of users are still really bad at passwords. Author here. I was originally planning to write a blog post about my experience reporting cryptography-related bugs to password managers in 2022. (I had findings for LastPass, 1Password, and Keeper.) My experience with LastPass was abysmal. I wrote a thread about it here: https…

Great article! Thanks for adding the mention to Dashlane, I appreciate it.

As a side note, since you are mentioning it, we use zxcvbn to check password strength and I hope we are going to add k-anonymity style checking for leaked passwords very soon :)

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#19
post #18

What is the recommended way of deriving a private key from a password and/or passphrase? Any pointers to relevant literature will also help.

Typically you don't need to know much more than what the libsodium docs tell you:

https://libsodium.gitbook.io/doc/password_hashing

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#20

[flagged]

"Stop enjoying things I don't like, that's bad. I'm going to go out of my way to create alt accounts to 'hide from being harassed' while doing the harassing!"

Nobody cares what you think. Everyone knows your beliefs are impotent by the need to generate a throwaway.

Post reply on HN