7 ms·

shadow – Cryptography with Passwords

98 points by psanford 4y ago

satish-setty 4y ago
Could someone (@dang ?) fix the title please? It is /etc/shadow , not /etc./Shadow
- deleted 4y ago
  [deleted]
- technion 4y ago
  There's a reason for this - having /etc/shadow in the title breaks searching from Algolia search due to a WAF. eg try this https://hn.algolia.com/?query=What%20We%20Do%20in%20the%20%2Fetc%2Fshadow%20%E2%80%93%20Cryptography%20with%20Passwords&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0 https://hn.algolia.com/?query=What%20We%20Do%20in%20the%20%2...
  - deleted 4y ago
    [deleted]
  - ivanr 4y ago
    That’s so depressing.
  - rtev 4y ago
    That WAF needs to be tuned. If they’re worried about the possibility of a local file read that can disclose /etc/shadow, there are much bigger issues.
    - thayne 4y ago
      Or it is defense in depth. Although blocking it even if the / is percent encoded seems a bit excessive, especially as a default.
  - thaumaturgy 4y ago
    ...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.
    - technion 4y ago
      I just hit a website I know has an entirely default config on the free plan as https://website/q=cat https://website/q=cat /etc/shadow and got the same exact error page.
      - some_furry 4y ago
        So much for CloudFlare's stance on free speech, I'm being censored for comedy! (The title is a wordplay on What We Do in the Shadows.) Joke aside, I can understand why, generally, protecting from /etc/shadow disclosures is a good default, but it should be possible to disable this particular protection. If anyone knows how, that'd be good to share. EDIT: A bypass has been discovered https://infosec.exchange/@jsmall/109647469548014823 https://infosec.exchange/@jsmall/109647469548014823
        arbol 4y ago
        It's a great title
      - thaumaturgy 4y ago
        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?
thaumaturgy 4y ago
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.
- some_furry 4y ago
  > 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 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 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 https://github.com/DivineOmega/password_exposed - Checks if a given password has been exposed in a previous breach (uses the HIBP hash database)
soatok_sicko 4y ago
[flagged]
- thefurdrake 4y ago
  "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.
_448 4y ago
What is the recommended way of deriving a private key from a password and/or passphrase? Any pointers to relevant literature will also help.
- TillE 4y ago
  Typically you don't need to know much more than what the libsodium docs tell you: https://libsodium.gitbook.io/doc/password_hashing https://libsodium.gitbook.io/doc/password_hashing
  - adrian_b 4y ago
    Yes, that is a very good choice. It uses the Argon2 algorithm (RFC9106). I have studied Argon2 and in my opinion it really is an improvement over the older methods.
  - _448 4y ago
    Thank you for the link! I will go through it. And is there a way to derive a public key using a derived private key, say, for example, by using ECC?
    - some_furry 4y ago
      crypto_box_seed_keypair() Or for signatures, crypto_sign_seed_keypair(). Use the output of Argon2 as the seed.
      - _448 4y ago
        Thank you very much. That was really helpful!
Oreko 4y ago
Hi, I perform research in the area of PAKEs. I'm not a "foremost expert" but I know a bit. Before I start, I don't believe that it's standard to use the term "doubly augmented PAKEs". Instead, I'll use the more accepted shorthand "saPAKE" for "strong asymmetric PAKE". I think it's important to note that the provided saPAKE Double BS-SPEKE does not come with a security proof. A proof of a similar protocol is not hard if you believe in the compiler provided in the JKX18 paper[1] and you believe that B-SPEKE is a UC-secure aPAKE but it's important to note that the JKX compiler is not proven secure against the updated functionality from their revisions. Further, I don't believe that B-SPEKE has a security proof in any model let alone the UC model. But I can say for certain that the currently described protocol is not a secure saPAKE as it doesn't prevent an adversary from impersonating a client after stealing the server's password file. The adversary learns (B, salt, P, C, s, b, regMAC) and needs to produce (a * P, H(idC, idS, A, B, a * B, c * B, s * A)) a is uniformly sampled, so the adversary knows a * P, A, B, a * B, and s * A. We're missing c * B, but this is just b * C which we know. So the adversary can produce all messages required and arrive at the server's key. This may not be a security guarantee that you need for your use case, but I cannot recommend Double BS-SPEKE as an saPAKE (or even an aPAKE) until we see a formalized analysis of its guarantees. [1] OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks https://eprint.iacr.org/2018/163 https://eprint.iacr.org/2018/163 --- EDIT --- I just came across the original talk https://www.youtube.com/watch?v=gopo2FI9epw https://www.youtube.com/watch?v=gopo2FI9epw using the term "doubly augmented" and I'll update this post soon. I'm still not sure what "doubly augmented" means, but the talk seems to conflate the security properties of OPAQUE and double BS-SPEKE as well as listing doubly augmented as a subset of augmented PAKEs.
- cendyne 4y ago
  The "augmented" label confused me a lot too. I saw Steve Thomas's presentation in person at DEF CON and could not find material online using that phrase outside of his materials.
  - Oreko 4y ago
    Augmented is a common label for these kind of PAKEs. Generally speaking, asymmetric, verifier-based, and augmented are all three interchangeable. Sc00bz made a comment[1] on reddit describing what "doubly augmented" means where they succinctly describe it as "A doubly augmented PAKE is where both sides can store data to authenticate with eachother but not themselves." This mirrors the definition of aPAKE and makes sense, but this sounds more like the security property provided by CRISP[2]. This doesn't make sense in the context of double BS-SPEKE as the client inputs their password in the clear which can be used to generate the server's storage without any "guessing". [1] https://old.reddit.com/r/crypto/comments/zy8w3y/what_we_do_in_the_etcshadow_cryptography_with/j2p053r/ https://old.reddit.com/r/crypto/comments/zy8w3y/what_we_do_i... [2] CHIP and CRISP: Protecting All Parties Against Compromise through Identity-Binding PAKEs https://eprint.iacr.org/2020/529 https://eprint.iacr.org/2020/529
Absolucy 4y ago
Useful uBlock Origin filter for this site: soatok.blog##figure:has(> figcaption:has-text(/Art by/)) soatok.blog##figure:has(> figcaption:has-text(/Art: /))

98 points by psanford 4y ago

satish-setty 4y ago

Could someone (@dang ?) fix the title please? It is /etc/shadow , not /etc./Shadow

deleted 4y ago
[deleted]
technion 4y ago
There's a reason for this - having /etc/shadow in the title breaks searching from Algolia search due to a WAF. eg try this https://hn.algolia.com/?query=What%20We%20Do%20in%20the%20%2Fetc%2Fshadow%20%E2%80%93%20Cryptography%20with%20Passwords&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0 https://hn.algolia.com/?query=What%20We%20Do%20in%20the%20%2...
- deleted 4y ago
  [deleted]
- ivanr 4y ago
  That’s so depressing.
- rtev 4y ago
  That WAF needs to be tuned. If they’re worried about the possibility of a local file read that can disclose /etc/shadow, there are much bigger issues.
  - thayne 4y ago
    Or it is defense in depth. Although blocking it even if the / is percent encoded seems a bit excessive, especially as a default.
- thaumaturgy 4y ago
  ...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.
  - technion 4y ago
    I just hit a website I know has an entirely default config on the free plan as https://website/q=cat https://website/q=cat /etc/shadow and got the same exact error page.
    - some_furry 4y ago
      So much for CloudFlare's stance on free speech, I'm being censored for comedy! (The title is a wordplay on What We Do in the Shadows.) Joke aside, I can understand why, generally, protecting from /etc/shadow disclosures is a good default, but it should be possible to disable this particular protection. If anyone knows how, that'd be good to share. EDIT: A bypass has been discovered https://infosec.exchange/@jsmall/109647469548014823 https://infosec.exchange/@jsmall/109647469548014823
      - arbol 4y ago
        It's a great title
    - thaumaturgy 4y ago
      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?

thaumaturgy 4y ago

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.

some_furry 4y ago
> 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 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 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 https://github.com/DivineOmega/password_exposed - Checks if a given password has been exposed in a previous breach (uses the HIBP hash database)

soatok_sicko 4y ago

[flagged]

thefurdrake 4y ago
"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.

_448 4y ago

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

TillE 4y ago
Typically you don't need to know much more than what the libsodium docs tell you: https://libsodium.gitbook.io/doc/password_hashing https://libsodium.gitbook.io/doc/password_hashing
- adrian_b 4y ago
  Yes, that is a very good choice. It uses the Argon2 algorithm (RFC9106). I have studied Argon2 and in my opinion it really is an improvement over the older methods.
- _448 4y ago
  Thank you for the link! I will go through it. And is there a way to derive a public key using a derived private key, say, for example, by using ECC?
  - some_furry 4y ago
    crypto_box_seed_keypair() Or for signatures, crypto_sign_seed_keypair(). Use the output of Argon2 as the seed.
    - _448 4y ago
      Thank you very much. That was really helpful!

Oreko 4y ago

Hi, I perform research in the area of PAKEs. I'm not a "foremost expert" but I know a bit. Before I start, I don't believe that it's standard to use the term "doubly augmented PAKEs". Instead, I'll use the more accepted shorthand "saPAKE" for "strong asymmetric PAKE". I think it's important to note that the provided saPAKE Double BS-SPEKE does not come with a security proof. A proof of a similar protocol is not hard if you believe in the compiler provided in the JKX18 paper[1] and you believe that B-SPEKE is a UC-secure aPAKE but it's important to note that the JKX compiler is not proven secure against the updated functionality from their revisions. Further, I don't believe that B-SPEKE has a security proof in any model let alone the UC model. But I can say for certain that the currently described protocol is not a secure saPAKE as it doesn't prevent an adversary from impersonating a client after stealing the server's password file. The adversary learns (B, salt, P, C, s, b, regMAC) and needs to produce (a * P, H(idC, idS, A, B, a * B, c * B, s * A)) a is uniformly sampled, so the adversary knows a * P, A, B, a * B, and s * A. We're missing c * B, but this is just b * C which we know. So the adversary can produce all messages required and arrive at the server's key. This may not be a security guarantee that you need for your use case, but I cannot recommend Double BS-SPEKE as an saPAKE (or even an aPAKE) until we see a formalized analysis of its guarantees. [1] OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks https://eprint.iacr.org/2018/163 https://eprint.iacr.org/2018/163 --- EDIT --- I just came across the original talk https://www.youtube.com/watch?v=gopo2FI9epw https://www.youtube.com/watch?v=gopo2FI9epw using the term "doubly augmented" and I'll update this post soon. I'm still not sure what "doubly augmented" means, but the talk seems to conflate the security properties of OPAQUE and double BS-SPEKE as well as listing doubly augmented as a subset of augmented PAKEs.

cendyne 4y ago
The "augmented" label confused me a lot too. I saw Steve Thomas's presentation in person at DEF CON and could not find material online using that phrase outside of his materials.
- Oreko 4y ago
  Augmented is a common label for these kind of PAKEs. Generally speaking, asymmetric, verifier-based, and augmented are all three interchangeable. Sc00bz made a comment[1] on reddit describing what "doubly augmented" means where they succinctly describe it as "A doubly augmented PAKE is where both sides can store data to authenticate with eachother but not themselves." This mirrors the definition of aPAKE and makes sense, but this sounds more like the security property provided by CRISP[2]. This doesn't make sense in the context of double BS-SPEKE as the client inputs their password in the clear which can be used to generate the server's storage without any "guessing". [1] https://old.reddit.com/r/crypto/comments/zy8w3y/what_we_do_in_the_etcshadow_cryptography_with/j2p053r/ https://old.reddit.com/r/crypto/comments/zy8w3y/what_we_do_i... [2] CHIP and CRISP: Protecting All Parties Against Compromise through Identity-Binding PAKEs https://eprint.iacr.org/2020/529 https://eprint.iacr.org/2020/529

Absolucy 4y ago

Useful uBlock Origin filter for this site: soatok.blog##figure:has(> figcaption:has-text(/Art by/)) soatok.blog##figure:has(> figcaption:has-text(/Art: /))