5 ms·

> It's important to remember that we are not encrypting the text here. Thank you for emphasizing this. Many junior devs have been bitten by not being told earl

> It's important to remember that we are not encrypting the text here. Thank you for emphasizing this. Many junior devs have been bitten by not being told early enough the difference between encryption (requires a secret to be reversed), hashing (cannot be reversed) and encoding (can always be trivially reversed). Also good to know that while the output looks random, it follows the same entropy as the input. Ie: don't base64 encode your password to make it stronger.

sirk390 3y ago
I really though you were going to say "Chat-GPT detected" when quoting that message.
globular-toast 3y ago
This is why computer science as a discipline matters.
deleted 3y ago
[deleted]
tinco 3y ago
This is a nitpick and not pertinent to anything, but base64 encoding your password could make it stronger. Password strength is not just about entropy, high entropy is simply the most effective way of making your password stronger. If your password is 100% randomly generated (as it should be) then base64 encoding it won't do anything. If however your password is engineered to be easier to remember, for example by using dictionaries or some kind of scheme that has a lower entropy, then the base64 encoding step adds a single bit of strength to your password. Meaning anyone who is brute forcing your password using a smart password cracker, has to configure that cracker to also consider base64 encoding as a scheme, basically forcing it to perform a single extra operation for every try. Anyway, useless information, you shouldn't be using password schemes like that. The horse shoe battery staple type password style should be quite sufficient I think.
- franky47 3y ago
  One could argue that base64 having a shorter output length than its input would weaken any given password, assuming a brute force attack (not a dictionary one).
  - LelouBil 3y ago
    Base64 turns 6 bits to a ASCII character (8 bits), I don't think it's possible to have a shorter output length.
    - franky47 3y ago
      Damn, indeed, my bad. In my defense, I just had a new baby and didn't sleep much last night..
      - iambateman 3y ago
        Congrats on the baby!
      - cortesoft 3y ago
        My brain never recovered from having kids. Good luck.
        jonny_eh 3y ago
        With each kid you add a brain to the world. So it's a net win?
        selcuka 3y ago
        > With each kid you add a brain to the world. So it's a net win? It depends... Is it the sum or the average that counts?
    - LinuxBender 3y ago
      Adding to this here [1] is a chart that shows how several encodings affect size ratios of utf-8, 16 and 32. Of course that gets into the discussions [2][3] of using utf in passwords and I have no idea how many password schemes support this beyond what I use. [1] - https://github.com/qntm/base2048 https://github.com/qntm/base2048 [2] - https://security.stackexchange.com/questions/85663/is-it-a-good-idea-to-use-non-latin-unicode-characters-in-a-password https://security.stackexchange.com/questions/85663/is-it-a-g... [3] - https://security.stackexchange.com/questions/4943/will-using-unicode-chars-in-my-password-increase-security https://security.stackexchange.com/questions/4943/will-using...
throw0101a 3y ago
> Many junior devs have been bitten by not being told early enough the difference between encryption (requires a secret to be reversed), hashing (cannot be reversed) and encoding (can always be trivially reversed). If they want to encrypt something just tell them to use ROT13 twice.
- xp84 3y ago
  This is dangerous and outdated advice. ROT13 should always be used an odd number of times to avoid CVE-2022-13!
osigurdson 3y ago
I would think every CS grad would know the difference between these things. Everyone interested in coding could learn these concepts in an afternoon.
- fud101 3y ago
  coding as in java or coding as in information theory?
  - bruce343434 3y ago
    as in cardiac arrest
- xp84 3y ago
  You and I would both think -- but on the other hand, I've interviewed a lot of people who have dispossessed me of that illusion. Seemingly simple concepts don't always stick.
CobrastanJorji 3y ago
A related thing always worth emphasizing: hashes aren't necessary cryptographically secure! Hashing has many purposes besides security, and for that reason there are many hash libraries. If you plan on using hashes for something related to security or cryptography, you need to use a hash designed for that purpose! Yes, CRC hashing is really fast, and that's great, but it's not great when you use it for user passwords.
- remram 3y ago
  Password-masking functions are not usually what's referred to as "cryptographically-secure hash", e.g. unsalted SHA-2 is one but not the other. For example resistance to enumeration or rainbow tables is not a requirement for cryptographic hash functions, but is important for good password-hashing functions. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Password-hashing_function https://en.wikipedia.org/wiki/Password-hashing_function
- fbdab103 3y ago
  Unless you have really specific requirements (hashes/second, hash size no bigger than X characters, etc) is there any reason not to default to sha256? I still see newly released projects that choose md5. Like, sure, for the intended use case, probably nobody will construct a collision, but why even allow the possibility?
  - franky47 3y ago
    It's not much about collisions, more like predictability of the output. You can trivially construct a rainbow table of the most common N passwords and test a dump of SHA-256 hashes against it. Also, SHA-256 is vulnerable to length extension attacks, so it may not be suitable in some applications on variable-length inputs. Generally speaking, hashing user-provided data as-is is only a guarantee of integrity, not of authenticity (see HMAC), nor secrecy.

sirk390 3y ago

I really though you were going to say "Chat-GPT detected" when quoting that message.

globular-toast 3y ago

This is why computer science as a discipline matters.

deleted 3y ago

[deleted]

tinco 3y ago

This is a nitpick and not pertinent to anything, but base64 encoding your password could make it stronger. Password strength is not just about entropy, high entropy is simply the most effective way of making your password stronger. If your password is 100% randomly generated (as it should be) then base64 encoding it won't do anything. If however your password is engineered to be easier to remember, for example by using dictionaries or some kind of scheme that has a lower entropy, then the base64 encoding step adds a single bit of strength to your password. Meaning anyone who is brute forcing your password using a smart password cracker, has to configure that cracker to also consider base64 encoding as a scheme, basically forcing it to perform a single extra operation for every try. Anyway, useless information, you shouldn't be using password schemes like that. The horse shoe battery staple type password style should be quite sufficient I think.

franky47 3y ago
One could argue that base64 having a shorter output length than its input would weaken any given password, assuming a brute force attack (not a dictionary one).
- LelouBil 3y ago
  Base64 turns 6 bits to a ASCII character (8 bits), I don't think it's possible to have a shorter output length.
  - franky47 3y ago
    Damn, indeed, my bad. In my defense, I just had a new baby and didn't sleep much last night..
    - iambateman 3y ago
      Congrats on the baby!
    - cortesoft 3y ago
      My brain never recovered from having kids. Good luck.
      - jonny_eh 3y ago
        With each kid you add a brain to the world. So it's a net win?
        selcuka 3y ago
        > With each kid you add a brain to the world. So it's a net win? It depends... Is it the sum or the average that counts?
  - LinuxBender 3y ago
    Adding to this here [1] is a chart that shows how several encodings affect size ratios of utf-8, 16 and 32. Of course that gets into the discussions [2][3] of using utf in passwords and I have no idea how many password schemes support this beyond what I use. [1] - https://github.com/qntm/base2048 https://github.com/qntm/base2048 [2] - https://security.stackexchange.com/questions/85663/is-it-a-good-idea-to-use-non-latin-unicode-characters-in-a-password https://security.stackexchange.com/questions/85663/is-it-a-g... [3] - https://security.stackexchange.com/questions/4943/will-using-unicode-chars-in-my-password-increase-security https://security.stackexchange.com/questions/4943/will-using...

throw0101a 3y ago

> Many junior devs have been bitten by not being told early enough the difference between encryption (requires a secret to be reversed), hashing (cannot be reversed) and encoding (can always be trivially reversed). If they want to encrypt something just tell them to use ROT13 twice.

xp84 3y ago
This is dangerous and outdated advice. ROT13 should always be used an odd number of times to avoid CVE-2022-13!

osigurdson 3y ago

I would think every CS grad would know the difference between these things. Everyone interested in coding could learn these concepts in an afternoon.

fud101 3y ago
coding as in java or coding as in information theory?
- bruce343434 3y ago
  as in cardiac arrest
xp84 3y ago
You and I would both think -- but on the other hand, I've interviewed a lot of people who have dispossessed me of that illusion. Seemingly simple concepts don't always stick.

CobrastanJorji 3y ago

A related thing always worth emphasizing: hashes aren't necessary cryptographically secure! Hashing has many purposes besides security, and for that reason there are many hash libraries. If you plan on using hashes for something related to security or cryptography, you need to use a hash designed for that purpose! Yes, CRC hashing is really fast, and that's great, but it's not great when you use it for user passwords.

remram 3y ago
Password-masking functions are not usually what's referred to as "cryptographically-secure hash", e.g. unsalted SHA-2 is one but not the other. For example resistance to enumeration or rainbow tables is not a requirement for cryptographic hash functions, but is important for good password-hashing functions. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Password-hashing_function https://en.wikipedia.org/wiki/Password-hashing_function
fbdab103 3y ago
Unless you have really specific requirements (hashes/second, hash size no bigger than X characters, etc) is there any reason not to default to sha256? I still see newly released projects that choose md5. Like, sure, for the intended use case, probably nobody will construct a collision, but why even allow the possibility?
- franky47 3y ago
  It's not much about collisions, more like predictability of the output. You can trivially construct a rainbow table of the most common N passwords and test a dump of SHA-256 hashes against it. Also, SHA-256 is vulnerable to length extension attacks, so it may not be suitable in some applications on variable-length inputs. Generally speaking, hashing user-provided data as-is is only a guarantee of integrity, not of authenticity (see HMAC), nor secrecy.