Hacker News Reader

Comment by nostromo | Hacker News Reader

Related, but different in an important way.

If your password is aBc, you can log in to Facebook using aBc (original), AbC (windows caps lock), and ABc (first cap) only. For a regular password, this is just slightly less secure.

Being case insensitive entirely is quite a bit less secure (abc, abC, aBc, aBC, Abc, AbC, ABc, ABC).

View on HN

I wonder how they do that. If they store the password hashed, wouldn't they have to normalize it two/three different ways and store a hash for each?

Or perhaps they aren't storing it hashed ...

Facebook won't make that mistake.

Facebook are not that stupid.

No, they only need to store a single hashed password. For authentication they can just try out the other 2 transformations above and see if any of them matches what's on file.

thereis no multiple transformations, they just lcase every pwd input before hashing. the stored hash is a the hash of the lcase pwd.

They have your un-hashed password when the form is submitted, they can try all three, hash them, and compare those to the saved hash.

They would only have to store a single hash - the proper password.

When you log in to Facebook, they hash the password you gave them and try that. If it fails, they modify the password you gave them, reversing the case on all letters (and possibly convert numbers to special characters, or vice versa - I don't know if they go that far), and hash that.

Remember that when you log in, the server is receiving your password in plain text. Facebook is just "massaging" that data a bit (possibly several times) to try to correct a user error, rather than just bailing at the first sign of trouble.

The only problem with that is that it's ripe for timing attacks. I _hope_ they always check all three passwords anyway.

Exposing the timing here can only tell you one thing: the password that you're trying works for Facebook, but the capitalization might be wrong if you're using it to get into the user's account on another site. But since there are only three variants on the password, it gives you effectively nothing. This would be insanely difficult to pull off (many, many login samples) for absolutely no payoff; they might as well save the extra hashes if it works the first time.

Hi, interested in the above comment. Can you explain how a timing attack would work here?

An interesting demo: [1] By not doing all 3 hashes, an attacker might realise that the password they sent passed, say, 2 checks, but not the third. This discloses information about the relationship between the password the attacker just tried and the correct password.

[1] http://carlos.bueno.org/2011/10/timing.html

I'm not sure how this is applicable here, if the attacker passes any of the tests then they are able to log in

Indeed, stupid logic on my part.

I see the problem in theory, but in reality, the time of a couple of hash functions compared to network latency and application server routing would be quite small. Can timing attacks actually work in such situations?

Can you do a timing attack against something as fast as a case conversion and a hash function, even if it has a work factor? Normally they're done against database requests aren't they?

"Remote Timing Attacks are Practical"

https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

I know you can do timing attacks through the network, it's not even that hard in the simple case.

That paper, like most papers on timing attacks, was done on the local network, not the internet. They're relying on absurdly precise measurements of absolutely tiny differences in timing, which would be lost in the jitter and latency of the real internet.

As I said, you can certainly do internet timing attacks where you're looking for database access, because this can take many milliseconds, which is a delay which can be detected even on a crappy internet link using a bit of light statistics.

Right; I guess my thought is that since a hash with a modest work function can also take many milliseconds, this would be meaningful. Not sure in practice, however.

You can't do a timing attack against a password hashed serverside, since you don't control the string being compared enough to make iterated byte-at-a-time changes.

Even if I'm misunderstanding, though, this particular remote timing attack is probably not practical in most programming environments; (for instance) straight C memcmp is below the measurement floor, even with signal processing.

That is a great paper; also, check out Crosby and Wallach for the modernized, math-ier take; with signal processing, the measurement limits are nanoseconds on a switched LAN (ie, if you could get a box deployed in the same hosting center as Blizzard) and tens of milliseconds over the Internet:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.9...

... and Nate Lawson's Black Hat talk which actually goes through the practical issues trying to set up and run these attacks against real systems:

http://www.youtube.com/watch?v=A0T8o-Aq3yY

There was a nice talk at 28c3 called "time is on my side" by Sebastian Schinzel, specifically about timing attacks over the net; it is pleasingly practical in its approach. He attacks the popular typo3 CMS.

http://www.youtube.com/watch?v=ykNt8pSQFZQ

It's very modern, as you describe, with all the fancy maths and all that.

This is really great. Thanks for sharing it.

Why not just lcase everything during initial hashing and later auth?

sha1sum(lcase($passwd). $salt);

because as nostromo said then uppercase counts for nothing. Facebook only lets you log in if you accidentally use cap-lock or accidentally capitalize the first letter(quite common on phones). If you lowercased the whole password first, you reduce the benefit of having uppercase characters at all.

Ah, I missed that, sorry.

I think the point stands for the Blizzard case - there seems to be an assumption in some corners that the password is stored plain text, but I would imagine case neutralised (so to speak) passwords are hashed.

there is no multiple transformations, they just lcase every pwd input before hashing. the stored hash is the hash of the lcase pwd.

I was referring to Facebook with my comment, not Diablo 3.

Facebook massages the data to allow you to login even if you have caps lock on, so "pASSWORD" works when your password is "Password", or if, e.g., your phone capitalizes the first character in your password, so "Password" works when your password is "password".

I don't under stand the confusion in the other replies here.

1) lowercase inputted password. 2) hash password 3) compare hash to db hash (which was from a lowercased initial password).

Because this isn't how they do it. that method is the same as the Blizzard method, and it is a lot less secure than transforming the plain text and trying the three different combinations(normal, uppercase first and capslock password)

Ah, sorry, I missed the top of this reply-thread. I was referring to the story, not Facebook. :-)

They could normalize it in the following way before storing a hash:

1. If the last letter in the string is uppercase, flip the case of the entire string.

2. Make the first character lowercase.

This would allow for abC as well (if you "capitalized" the first letter while holding down capslock).

Reply on news.ycombinator.com