4

When coming up with a password based login protocol, many solutions come in mind:

  1. User sends password in plain text. Compute hash on Server, compare to hash in database. - Bad because attacker can intercept credentials
  2. User sends hash of password, server compares hash to hash in database. - Bad because attacker can intercept hashed password, which is just as good as credentials.
  3. Server sends user a temporary salt, user computes normal hash, then sends salted hash of original hash to server. Server gets original hash from database, computes salted hash and compares. - Bad because if the hash database leaks the attacker doesn't need to crack hashes
  4. Set up a secure connection (e.g. SSL/TLS), then proceed as in 1) - Bad because all the work done on server
  5. Set up a secure connection (e.g. SSL/TLS), then proceed as in 2) - Bad because if the hash database leaks the attacker doesn't need to crack hashes

I would guess that number 4) is the way to go. Is that correct or are there better ways?

P.S: When I write "hash" I mean a moderately expensive hash function such as 100'000 iterations of sha256.

Improve this question
4
  • 2
    For a clever alternative, look at SRP
    – paj28
    Jul 6, 2015 at 13:03
  • en.wikipedia.org/wiki/Kerberos_(protocol)
    – Sobrique
    Jul 6, 2015 at 16:37
  • A better link for SRP at Wikipedia: Secure Remote Password protocol. Cool stuff, thanks @paj28
    – Adam Katz
    Jul 10, 2015 at 1:50
  • The login is always a login to something. If there's a need to have a log in mechanism then presumably there is a requirement for security around the resources to be protected by the login, and that in itself is a reason to use something like TLS even before thinking about password security concerns.
    – bdsl
    Nov 10, 2016 at 22:54

1 Answer 1

Reset to default
9

Secure Communication

The communication protocol must be secure. If the communication channel is insecure then the authentication is insecure. TLS/SSL is one way to secure the communication protocol. If you don't use TLS/SSL you would need to build a framework to build a secure communication protocol over an insecure link. If done properly (authentication of server, authentication of client, secure key exchange, encryption, message authentication, robust handling of downgrades, etc) the protocol would be complex. For all practical purposes you would just end up reinventing TLS/SSL.

So as written only #4 and #5 are secure and for most applications #4 should be the primary choice. This isn't to say you must always use #4 but you should be able to clearly articulate why in this scenario #4 is inferior to an alternative.

Zero Knowledge (deniability)

A variant of #5 can be useful in niche applications where zero knowledge or deniability is a core design requirement. Understand that is adds additional complexity so if you don't need deniability you are building a more complex system without improving security. Higher complexity means higher cost and greater possibility of introducing weaknesses which can be exploited.

An example of where zero knowledge authentication would be useful would be an online backup service. If the server has the encryption keys the service can be forced to reveal them (potentially covertly and without due process). If the server never has the encryption keys then they can't be forced to reveal what they don't know.

The raw file encryption is pretty straightforward. The encryption key is generated from the user's password by using a KDF. Files are encrypted client side and transmitted to the server. The server never has the user's password or encryption key. The challenge is how to authenticate the user (for verifying account status, billing, allowing uploads, etc). The default process of the user sending the password (#4) defeats the client side encrypting of data. So the site could have the user take the password hash it client side and supply that to the server. The hash should be produced differently from the encryption key (same kdf but different number of rounds or same password but a static prefix). One improvement over what you laid out would be that the server doesn't have to store the user's authentication hash directly. The server can store a hash of the hash which would prevent false authentication even if the password list is compromised.

Asymmetric Cryptography for Authentication

An option not listed would be to use an client side certificate to authenticate the client. The cert creation, management and secure storage/backup needs to be done completely client side or there is no point. The private key can be encrypted with client side password for additional security. TLS/SSL supports client side certificates so if this is a design requirement I would start there rather than reinvent the wheel. One advantage of ECC over RSA is it is more friendly to low powered and memory constrained devices like smartcards so this is becoming a more realistic solution although user education is still a challenge.

Improve this answer
3
  • Only thing I have to add is SRP is a zero-knowledge protocol. Only the client knows the password. This is particularly useful in the instances you described.
    – user79537
    Jul 6, 2015 at 15:36
  • 1
    Though it would be ideal, TLS isn't solving this in practice because the server will almost never require a certificate from the client to prove its identity. SmartCards that supply these client certs work, but are a logistical headache outside of a centralized environment (like the military). Because passwords may be reused among sites, it's also not a good idea to send the plain-text password to an authenticated server. But this is often done because many backend systems are not design to securely delegate challenge/response up to the user (ie: they want a password).
    – Rob
    Jul 6, 2015 at 17:54
  • There is nothing wrong with sending "plain text" password inside an encrypted tunnel (TLS) to an authenticated server. Certs are obviously a superior choice (especially if encrypted w/ password derived key) but if limited to authenticating by credentials (username & password) client side hashing doesn't magic away the problems if the server is compromised.
    – Gerald Davis
    Jul 12, 2015 at 17:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .