Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
4 added 208 characters in body
source | link

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.


The use-case where I saw this is that accounts are initially created by an automation script thatas part of a several hour bulk process, and we don't trust withwould rather not have the plaintext passwords, then all floating around in memory / on disk during that time. All subsequent logins by the user will be directly to the service over a secure channel (note: not https, I mean "sign the logbook to get physical access to the room" type of secure channel).

To address comments, the reason we don't trust the automation script is that it is written in a language with immutable strings and garbage collection, so any memory containing passwords will be returned to the OS un-zeroized - which does not meet our internal policies for password handling. So yes, the main concern is a passive MitM.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.


The use-case where I saw this is that accounts are initially created by an automation script that we don't trust with the plaintext passwords, then all subsequent logins by the user will be directly to the service over a secure channel.

To address comments, the reason we don't trust the automation script is that it is written in a language with immutable strings and garbage collection, so any memory containing passwords will be returned to the OS un-zeroized - which does not meet our internal policies for password handling.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.


The use-case where I saw this is that accounts are initially created by an automation script as part of a several hour bulk process, and we would rather not have the plaintext passwords floating around in memory / on disk during that time. All subsequent logins by the user will be directly to the service over a secure channel (note: not https, I mean "sign the logbook to get physical access to the room" type of secure channel).

To address comments, the reason we don't trust the automation script is that it is written in a language with immutable strings and garbage collection, so any memory containing passwords will be returned to the OS un-zeroized - which does not meet our internal policies for password handling. So yes, the main concern is a passive MitM.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

3 added 300 characters in body
source | link

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

 

The use-case where I saw this is that accounts are initially created by an automation script that we don't trust with the plaintext passwords, then all subsequent logins by the user will be directly to the service over a secure channel.

To address comments, the reason we don't trust the automation script is that it is written in a language with immutable strings and garbage collection, so any memory containing passwords will be returned to the OS un-zeroized - which does not meet our internal policies for password handling.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

The use-case where I saw this is that accounts are initially created by an automation script that we don't trust with the plaintext passwords, then all subsequent logins by the user will be directly to the service over a secure channel.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

 

The use-case where I saw this is that accounts are initially created by an automation script that we don't trust with the plaintext passwords, then all subsequent logins by the user will be directly to the service over a secure channel.

To address comments, the reason we don't trust the automation script is that it is written in a language with immutable strings and garbage collection, so any memory containing passwords will be returned to the OS un-zeroized - which does not meet our internal policies for password handling.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

    Tweeted twitter.com/StackSecurity/status/831984397708582914
2 added 136 characters in body
source | link

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for aan account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

The use-case where I saw this is that accounts are initially created by an automation script that we don't trust with the plaintext passwords, then all subsequent logins by the user will be directly to the service over a secure channel.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach. 

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for a password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

The use-case where I saw this is that accounts are initially created by an automation script that we don't trust with the plaintext passwords, then all subsequent logins by the user will be directly to the service over a secure channel.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

1) User types password "FuzzyCat" into a client-side app.

2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

3) Server stores "99476bb..." in the database as the password hash for that user.

4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

The use-case where I saw this is that accounts are initially created by an automation script that we don't trust with the plaintext passwords, then all subsequent logins by the user will be directly to the service over a secure channel.


Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach. 

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

1
source | link