Re: Time Invariant String Comparison

On Thu, Jan 16, 2014 at 4:12 PM, William Ahern <william@25thandclement.com> wrote:

On Thu, Jan 16, 2014 at 05:15:51PM +0100, Pierre Chapuis wrote:
> > On Thu, Jan 16, 2014 at 5:01 AM, Oliver Kroth <oliver.kroth@nec-i.de>
> > wrote:
> >> Why not use hashed passwords, which is a better idea anyway as this
> >> takes a
> >> length independent time, and you may store the credentials in a safe
> >> way?
> >
> > This is the best solution to the problem. The hashing function has
> > fixed-length output making the comparison immune to timing attacks,
> > and its own execution time is based only on the length of the input
> > and leaks no information about the real password.
>
> +1. If you are storing passwords in cleartext timing attacks should
> be the least of your worries. Use a good hashing function instead,
> like bcrypt [1], scrypt or PBKDF2. See [2] to understand why those
> ones and not generic hashing functions.
>
> [1] https://github.com/mikejsavage/lua-bcrypt
> [2] http://codahale.com/how-to-safely-store-a-password/

Cryptographic security depends on exponential cost differences. Key
stretching solutions like bcrypt and PBKDF2 add linear costs. Their security
is, therefore, mostly hype, IMNSHO.

Salting gives you a better bang for your buck. Fortunately, both bcrypt and
PBKDF2 incorporate salting. Their true value lies not in their convoluted
stretching schemes, but in the fact that they also incorporate other useful
features, and that you can download them as libraries that are hard to screw
up using.

You guys are forgetting that Lua hashes strings internally. Therefore there's no need to hash your passwords!

(I kid, I kid.)

In all seriousness:
-If you're comparing secrets, DO use a compare function that doesn't stop when it finds a mismatch, like the one someone had posted earlier in this thread. That eliminates the problem of leaking information about the password length.
-DON'T just add random delays - that's just adding more noise that can be filtered by increasing the sample size.
-DO add more delay for each incorrect attempt, and/or block IPs that try too many incorrect passwords.

-DON'T lock accounts that have too many incorrect attempts. That allows an attacker to lock legitimate users out of their accounts.

-ALWAYS salt and hash your passwords! Then there's no possibility of a timing attack AND no need to restrict which characters can be used or how long the password can be. (But do impose a maximum length of, say, a few hundred bytes, so that people can't DoS your service by repeatedly trying to log in with multi-megabyte passwords that your system will need to hash before checking.)

--
Sent from my Game Boy.