Skip to main content
Information Security

Return to Answer

s/it isn/t/but it isn't/
Source Link
Bob Brown
Bob Brown
  • 5.3k
  • 1
  • 21
  • 29

Edited to add: It turns out that what I've written is correct, but it isn't an answer to the question that was asked. I apologize.

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm

Edited to add: It turns out that what I've written is correct, it isn't an answer to the question that was asked. I apologize.

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm

Edited to add: It turns out that what I've written is correct, but it isn't an answer to the question that was asked. I apologize.

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm

What I wrote diesn't answer the question.
Source Link
Bob Brown
Bob Brown
  • 5.3k
  • 1
  • 21
  • 29

Edited to add: It turns out that what I've written is correct, it isn't an answer to the question that was asked. I apologize.

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm

Edited to add: It turns out that what I've written is correct, it isn't an answer to the question that was asked. I apologize.

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm

Source Link
Bob Brown
Bob Brown
  • 5.3k
  • 1
  • 21
  • 29

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm