6 ms·

And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this i

And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored. The only solution is correct access segregation and a bastion

jjk7 5mo ago
Assuming you're serious? Store passwords with salted one-way hashes.
- BrandoElFollito 5mo ago
  (I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
jm_l 5mo ago
Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.
- Tangurena2 5mo ago
  Also, you need to add salt. Otherwise every person using "Password123" has the exact same hash. Before they broke their search engine, it was common to google the MD5/MD4 hashes to "decrypt" or "unhash" them.
  - necovek 5mo ago
    And rainbow tables appeared too.
- CyberLily 5mo ago
  Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the client, and sent to the server the attacker doesn't need to reverse the hash, they can just send the hash in the request. Instead, you should send the password to the server (using TLS encryption) and do the hash and compare on the server.
  - jmull 5mo ago
    You actually want to one-way passwords both client-side, for transport, and again server-side, for storage/comparison. Otherwise, there's a hole, between the end of the TLS connection and where the server-side encryption happens, where the password is in plain text. Think logs and load-balancers and proxies. While the client-side hashing doesn't help protect your site a lot (as you say, the hashed value the client sends effectively becomes the password), it helps protect the users who use the same password across multiple sites. Notice in this case, that's exactly what the brothers are accused of doing: using credentials harvested from their site to log into other, potentially more lucrative accounts. I didn't see if that's the hole the brothers exploited but it very well could have been. The client-side encryption may have been all that was missing in this case.
Epa095 5mo ago
Hashed, you store them hashed (and salted). A breach should never reveal passwords.
- BrandoElFollito 5mo ago
  (I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
Dangeranger 5mo ago
You should never store passwords in plain-text, encrypted or not, you should always use a one-way cryptographic hash like bcrypt [0], scrypt [1], or PBKDF2 [2], combined with a single use salt [3] and optionally a pepper [4], and then store the output of the hash in the database. To confirm a user supplied password matches you run input into the same hash function again with the salt+pepper and compare it to the value in the database. That way if the database is stolen, the attacker cannot recover the contents of the passwords without brute forcing them. Encrypting passwords is not recommended because too often attackers are able to recover the encryption keys during the same attack where the password data is extracted. [0] https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt [1] https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Scrypt [2] https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2 [3] https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) [4] https://en.wikipedia.org/wiki/Pepper_(cryptography) https://en.wikipedia.org/wiki/Pepper_(cryptography)
- BrandoElFollito 5mo ago
  (I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
ellg 5mo ago
I hope youre joking
- BrandoElFollito 5mo ago
  (I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
kjs3 5mo ago
I don't think those words mean what you think they mean.
- BrandoElFollito 5mo ago
  (I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
  - kjs3 5mo ago
    You should have stuck with the 'My bad...' and left out the eye-roll inducing humble brags and inscrutable non-clarifications. But what do I know...I've only been an infosec practitioner since the early 90s...I'm sure 'conference experience' trumps that. (I will not 'be copy/paste' (?) this response everywhere you spammed someone who pointed out the glaringly obvious)
    - BrandoElFollito 5mo ago
      Or I could have let it go. See, I respect people who point out mistakes, and explain why I did it. Why did I mention that I do security? Because I spent the last, 25 years trying to push proper practices and did not want to jump into discussions where over 10 comments we would end up flexing about details. Since you are an infosec practitioner since the early 90s you either are a saint, or did not have to yell through best practices to just let it go. Not sure what you don't like about conferences? Never got anything from them? I did and I am sure glad to have listened to great presentations.
__turbobrew__ 5mo ago
You speak very authoritatively on something you don’t know. Hashing passwords has been a thing for at least 50 years now. V3 unix had /etc/passwd which hashed all user passwords. Notably, these hashed passwords in early unix have been cracked: https://arstechnica.com/information-technology/2019/10/forum-cracks-the-vintage-passwords-of-ken-thompson-and-other-unix-pioneers/ https://arstechnica.com/information-technology/2019/10/forum... I guess you got your answer.
- BrandoElFollito 5mo ago
  (I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
subscribed 5mo ago
You don't store passwords. You store safely crafted hashes.
- BrandoElFollito 5mo ago
  (I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
  - subscribed 5mo ago
    Thanks for the follow up! And yeah, I share your gripe with the next target :)

jjk7 5mo ago

Assuming you're serious? Store passwords with salted one-way hashes.

BrandoElFollito 5mo ago
(I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)

jm_l 5mo ago

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

Tangurena2 5mo ago
Also, you need to add salt. Otherwise every person using "Password123" has the exact same hash. Before they broke their search engine, it was common to google the MD5/MD4 hashes to "decrypt" or "unhash" them.
- necovek 5mo ago
  And rainbow tables appeared too.
CyberLily 5mo ago
Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the client, and sent to the server the attacker doesn't need to reverse the hash, they can just send the hash in the request. Instead, you should send the password to the server (using TLS encryption) and do the hash and compare on the server.
- jmull 5mo ago
  You actually want to one-way passwords both client-side, for transport, and again server-side, for storage/comparison. Otherwise, there's a hole, between the end of the TLS connection and where the server-side encryption happens, where the password is in plain text. Think logs and load-balancers and proxies. While the client-side hashing doesn't help protect your site a lot (as you say, the hashed value the client sends effectively becomes the password), it helps protect the users who use the same password across multiple sites. Notice in this case, that's exactly what the brothers are accused of doing: using credentials harvested from their site to log into other, potentially more lucrative accounts. I didn't see if that's the hole the brothers exploited but it very well could have been. The client-side encryption may have been all that was missing in this case.

Epa095 5mo ago

Hashed, you store them hashed (and salted). A breach should never reveal passwords.

BrandoElFollito 5mo ago
(I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)

Dangeranger 5mo ago

You should never store passwords in plain-text, encrypted or not, you should always use a one-way cryptographic hash like bcrypt [0], scrypt [1], or PBKDF2 [2], combined with a single use salt [3] and optionally a pepper [4], and then store the output of the hash in the database. To confirm a user supplied password matches you run input into the same hash function again with the salt+pepper and compare it to the value in the database. That way if the database is stolen, the attacker cannot recover the contents of the passwords without brute forcing them. Encrypting passwords is not recommended because too often attackers are able to recover the encryption keys during the same attack where the password data is extracted. [0] https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt [1] https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Scrypt [2] https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2 [3] https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) [4] https://en.wikipedia.org/wiki/Pepper_(cryptography) https://en.wikipedia.org/wiki/Pepper_(cryptography)

BrandoElFollito 5mo ago
(I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)

ellg 5mo ago

I hope youre joking

BrandoElFollito 5mo ago
(I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)

kjs3 5mo ago

I don't think those words mean what you think they mean.

BrandoElFollito 5mo ago
(I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
- kjs3 5mo ago
  You should have stuck with the 'My bad...' and left out the eye-roll inducing humble brags and inscrutable non-clarifications. But what do I know...I've only been an infosec practitioner since the early 90s...I'm sure 'conference experience' trumps that. (I will not 'be copy/paste' (?) this response everywhere you spammed someone who pointed out the glaringly obvious)
  - BrandoElFollito 5mo ago
    Or I could have let it go. See, I respect people who point out mistakes, and explain why I did it. Why did I mention that I do security? Because I spent the last, 25 years trying to push proper practices and did not want to jump into discussions where over 10 comments we would end up flexing about details. Since you are an infosec practitioner since the early 90s you either are a saint, or did not have to yell through best practices to just let it go. Not sure what you don't like about conferences? Never got anything from them? I did and I am sure glad to have listened to great presentations.

__turbobrew__ 5mo ago

You speak very authoritatively on something you don’t know. Hashing passwords has been a thing for at least 50 years now. V3 unix had /etc/passwd which hashed all user passwords. Notably, these hashed passwords in early unix have been cracked: https://arstechnica.com/information-technology/2019/10/forum-cracks-the-vintage-passwords-of-ken-thompson-and-other-unix-pioneers/ https://arstechnica.com/information-technology/2019/10/forum... I guess you got your answer.

BrandoElFollito 5mo ago
(I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)

subscribed 5mo ago

You don't store passwords. You store safely crafted hashes.

BrandoElFollito 5mo ago
(I will be copy/paste this answer for the other comments) My bad - I misread the post. To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :) My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc. I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones. So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :) In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
- subscribed 5mo ago
  Thanks for the follow up! And yeah, I share your gripe with the next target :)