3

I am implementing a service where application-specific passwords seem a good choice to improve security. A question on why and when they might make sense has already been discussed here Google Account: implications of using application-specific passwords

Now, I am interested in the how, especially with strong hashes like bcrypt or scrypt.

  • I assume that Google, iCloud & Co store hashes of the app-specific passwords.
  • Given that all the app-specific passwords map to the same username, does that mean that one has to compare the hash of the given password to all known hashes of the given username?
  • If so, and say I use an encryption algorithm like bcrypt or scrypt with maxtime somewhere between 100 to 200 milliseconds, wouldn't I have to parallelise the hashing & comparison to minimise worst-case waiting time?
  • Is there a good reason why they chose not to use application-specific usernames? e.g. say, I have an account "foo" and ":" is not allowed in a user name, why not use "foo:bar" as the bar-app-specific username of the "foo" account? That way, the relation username <-> password is 1:1 again. Is that because users should not have to remember multiple names?

Many thanks for your thoughts.

Community
  • 1
RobS
  • 31
  • 2
  • Now, a couple of hours later I see a flaw in my thinking (thanks SJOPM for pointing me in the right direction): Of course I don't have a worst-case time of n * 200ms if my maxtime is 200ms and n is the number of user passwords. It's just 200ms + n (cheap) comparisons. This seems true for scrypt if the CPU cost parameter is the same for all of the user's passwords. For bcrypt however, this only works if all the user's passwords use the same salt, which doesn't smell good... – RobS Apr 08 '15 at 15:06

1 Answers1

1

I didn't implement such a system.
But I can still answer your questions (I hope).

A different password for each application is a nice feature to enhance security, so that a broken password won't immediatly give you access to all apps.

The problem with logging in with a different password for each application is the amount of passwords. Google has like 10 apps, so you'd have to remember 10 different (good) passwords which is pretty unlikely for a standard user, who'd just use one and the same for all services (may be even a bad one). Without a password manager this burden is impossible to overcome and people will start complaining because they say: "Hey, I logged in once, isn't that enough!?"

Technically there's (nearly) no difference in speed between multiple-passwords and a single password. If I'd implement such a system I'd go with sort of the second approach you mentioned, so tag a username with the app he's using (maybe not in the string as this may cause some mean attacks, but with some associated data). So the user logs in, provides his password, you open your app's password database, look the name up, do the password-hash and compare the computed tag with the stored tag. If they match, you grant access, if not you refuse access.

If you'd be storing a bunch of tags with the same username (which would be stupid as it would allow the user to use multiple passwords for the same account and hence limiting strength to the strength of the worst password), you'd simply calculate the tag once (assuming you used the same salt) and look for matches. If you were clever, you've used different salts and hence introduce a severe performance penalty. (worst case log in time grows linear with number of accounts), unless you can parallelize, which might slow-down log-in of other users, as they have to wait for the cpu-time they need for log-in.

SEJPM
  • 9,540
  • 6
  • 37
  • 67
  • SOJPM, many thanks for your comments. Yes, I came to realise that my line of thought was broken with regards to the worst-case time (if not using different salts for bcrypt). The thing with remembering passwords doesn't seem that much of a problem to me: app-specific passwords like at Google and iCloud are meant to be entered once and saved by the application (for the good and bad). Still, I wonder why they chose to use the same username for all passwords. I do not see any other reason than user convenience. – RobS Apr 08 '15 at 15:12
  • don't underestimate the value of user convenience. If users don't like your products, because they are too hard to use they won't use them even if they are highly secure. – SEJPM Apr 08 '15 at 15:56