4

I'm reading a lot about implementing security constraints to a REST API.

There are a lot of methods, some better than others for 3party applications or to consume my own API.

  • HTTP Basic + TLS (with keys)
  • HTTP Digest + TLS
  • OAuth 1.0a, 2.0
  • Application-only-auth (with keys) link
  • Amazon Signature Version 4 Link

To consume my own API I have 3 options (from low to high degree of difficulty to implement, always using TLS!):

  1. HTTP Basic + TLS (with keys)
  2. HTTP Digest + TLS
  3. Application-only-auth (with keys)
  4. Amazon Signature Version 4

The only benefit of digest over basic+tls is that the password is not transferred in plaintext but in an MD5 Hash.

But according to kbcert and wikipedia they say that MD5 must not be used (collision attacks).

My question is, If MD5 security is compromised (today and in the near future) 2. HTTP Digest + TLS is not a viable option to consume my own API and I only have the others "more" secure options (1, 3, 4)?

I know that HTTP Basic+TLS can have replay attacks.

dr jimbob
  • 38,936
  • 8
  • 92
  • 162
Diego Alvarez
  • 161
  • 1
  • 5

2 Answers2

5

Collision attacks are not relevant to the use of a hash function in the "Digest" authentication; that one uses preimage resistance for which MD5 is still quite sturdy.

Note that as long as you use SSL/TLS (i.e. HTTPS) then you can use Basic authentication: the SSL layer ensures that the password does not travel "as cleartext", and also that it is sent only to the rightful server. Also note that without SSL/TLS, you have other problems beyond authentication, e.g. hostile hijack of the connection after the authentication phase. For reasonable security, you really need SSL, and once you have SSL, then Basic authentication is fine.

In fact, Digest authentication introduces extra issues, not because of MD5, but because it forces the server to have a copy of the password; so the server must store the passwords "as is", and any local read-only breach on the server becomes critical. With Basic authentication, the server only needs to store hashed passwords (with a good password hashing function), and that's much better.

So don't use Digest, use Basic. But it is not a matter of "MD5 weakness"; Digest with SHA-256 would be no better.

As for OAuth, its main use is to delegate authentication, which may or may not be a good idea in your case, but is another matter altogether.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Digest auth requires server to store `MD5(user:realm:password)`, not plaintext, but given the speed at which basic MD5 (or any single-iteration hash function) can be cracked, that's not really much of a difference. – bonsaiviking Oct 11 '13 at 16:03
  • @thomas tks, I now understand that MD5 has no problems when is used as a password hash. Link to your post :) http://security.stackexchange.com/a/31846/31682 So, the problem with digest is not MD5, is the part when you need to store the password, I'm ok? But, I still don't get the part MD5 -> 'store the passwords "as is", and any local read-only breach on the server becomes critical.' 1. What do you mean "as is"? 2. Has any sense to store the password in this way?: bcrypt(MD5(password)+salt) ? – Diego Alvarez Oct 11 '13 at 19:33
  • @d1egoaz: No, it is NOT secure to use plain MD5 as a password hashing solution, especially as it is a quick hash function. What Thomas means is that if you use Digest authentication the server needs to store a plain-MD5 version of the password. Even if you use a separate and more secure hashing algorithm at the back end such as Bcrypt, it won't matter, as the attacker would choose to take the stored plain MD5 hashed password instead. – Nasrus Oct 12 '13 at 01:30
0

It's your threat model to determine. Basic auth is a good candidate if you have one system doing the password checking, and exposed endpoint.

Username and password in the basic form should work fine over TLS if you trust your certificates are safe and your endpoint isn't compromised. If it is compromised, the intruder can siphon the plaintext passwords from the requests.

Amazon's method is the best. You can delegate signature checking to secure systems that know the key. If the endpoint is compromised, you don't lose passwords because they are never sent in the request.

I don't know digest well enough. It's not used very much.

Jonathan
  • 2,318
  • 13
  • 16