4 ms·

My site would fall under this and I use two layer sha-2 512 keys with unique salts... just because I send you one email does not mean I know your password (and

My site would fall under this and I use two layer sha-2 512 keys with unique salts... just because I send you one email does not mean I know your password (and for that matter somehow you have to be given an initial password in a lot of systems)

EvanAnderson 14y ago
I'm unclear what you mean when you say "and I use two layer sha-2 512 keys with unique salts". The Plain-Text Offenders site is concerned with web sites that can email you back your original password in plain text. Personally, I'd be most concerned when these emails are in response to an "I forgot my password" request. (Initial registration emails that send you back your plaintext password are dumb, but don't necessarily indicate that the site operator can reconstruct your plaintext password.) If you are physically incapable of reconstructing the user's plaintext password and emailing it back to them then I'd say you're in good shape. If you have enough information to reconstruct the plaintext password then you're doing it wrong.
marshray 14y ago
Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database, will he then have a password equivalent that allows him to login as the users? Will it enable him to mount brute-force attacks against the users' plaintext passwords?
- lazyjones 14y ago
  > Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database, More pedantry: if you have a decent RDBMS like Postgres and connect to the DB always as some user A (using a Pg function with SECURITY DEFINER defined by a superuser to compare passwords with a delay, hashed or not) and use column-level permissions that disallow access to the password (or hash) column to non-superusers, they can sql inject all they want (any attempt to dump/select the password column will fail, unless they also manage to reconnect to the database as superuser).
  - EvanAnderson 14y ago
    I like RDBMS security (and I think it needs to be employed more frequently), but there's still no valid reason to ever store a plaintext (or plaintext-equivalent) password. Storing something toxic in a "safe" way doesn't make what's being stored any less toxic. The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage.
    - lazyjones 14y ago
      > The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage. I disagree, because what seems safe today might be unsafe tomorrow or in 10 years. Does anyone still remember Unix versions without a shadow passwd file? I do ... But why do we use that even today when modern Linux installations use SHA variants by default?
      - marshray 14y ago
        Because 50% of typical users will choose one of the top 10,000 most-common passwords and no practical amount of work factor will save them if the hashes become known.
        lazyjones 14y ago
        Consequently, DB column permissions are also worth it because they hide the hashes, while such people are not protected at all by current hashing schemes. The Postgres function written to compare passwords/hashes can also limit the number of checks per time unit to prevent brute-forcing.
  - marshray 14y ago
    People keep using this word 'pedantry'. I think I posed a very real-world and relevant concrete scenario with considerations that are usually worth thinking about.
omervk 14y ago
You should never be able to retrieve the original password. And why use a custom scheme when there's quite a few very good methods like bcrypt et al that we mention on the website?

EvanAnderson 14y ago

I'm unclear what you mean when you say "and I use two layer sha-2 512 keys with unique salts". The Plain-Text Offenders site is concerned with web sites that can email you back your original password in plain text. Personally, I'd be most concerned when these emails are in response to an "I forgot my password" request. (Initial registration emails that send you back your plaintext password are dumb, but don't necessarily indicate that the site operator can reconstruct your plaintext password.) If you are physically incapable of reconstructing the user's plaintext password and emailing it back to them then I'd say you're in good shape. If you have enough information to reconstruct the plaintext password then you're doing it wrong.

marshray 14y ago

Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database, will he then have a password equivalent that allows him to login as the users? Will it enable him to mount brute-force attacks against the users' plaintext passwords?

lazyjones 14y ago
> Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database, More pedantry: if you have a decent RDBMS like Postgres and connect to the DB always as some user A (using a Pg function with SECURITY DEFINER defined by a superuser to compare passwords with a delay, hashed or not) and use column-level permissions that disallow access to the password (or hash) column to non-superusers, they can sql inject all they want (any attempt to dump/select the password column will fail, unless they also manage to reconnect to the database as superuser).
- EvanAnderson 14y ago
  I like RDBMS security (and I think it needs to be employed more frequently), but there's still no valid reason to ever store a plaintext (or plaintext-equivalent) password. Storing something toxic in a "safe" way doesn't make what's being stored any less toxic. The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage.
  - lazyjones 14y ago
    > The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage. I disagree, because what seems safe today might be unsafe tomorrow or in 10 years. Does anyone still remember Unix versions without a shadow passwd file? I do ... But why do we use that even today when modern Linux installations use SHA variants by default?
    - marshray 14y ago
      Because 50% of typical users will choose one of the top 10,000 most-common passwords and no practical amount of work factor will save them if the hashes become known.
      - lazyjones 14y ago
        Consequently, DB column permissions are also worth it because they hide the hashes, while such people are not protected at all by current hashing schemes. The Postgres function written to compare passwords/hashes can also limit the number of checks per time unit to prevent brute-forcing.
- marshray 14y ago
  People keep using this word 'pedantry'. I think I posed a very real-world and relevant concrete scenario with considerations that are usually worth thinking about.

omervk 14y ago

You should never be able to retrieve the original password. And why use a custom scheme when there's quite a few very good methods like bcrypt et al that we mention on the website?