Topic: [RFC] 2-factor auth for exchanges (Read 2967 times)

bewildered

There are further problems with SMS messages. I've read today about guy that setup 2-factor authentication on Facebook (based on SMS messages and with NO fallback mechanism). One day his phone just stopped receiving these SMS messages. It is uncertain where was the fault (he could still receive other SMS messages, but not from Facebook), but the problem exists - relying on cellular network to get this working CAN fail. I have 2-factor SMS based auth in my bank, and you can just imagine my frustration when I want to do a transaction quickly and the SMS doesn't arrive. It happened to me quite a few times. On the other side relying on application that generates tokens solely based on an open algorithm and secret key on the device is much more trustworthy.

A company like the South African Clickatel charges something like the equivalent of 1-2 domestic sms'es (they're priced in ‘credits’ and the price in credits depends on destination and the amount of credits you purchase at a time) and they have an API to ease things.

Cheers,

When thinking in terms of different authentication factors, there are primarily 3. What you know, what you have and who you are. 2-factor auth uses 2 of those methods. It is unwise to use one method twice. Keeping it what you know (password) and what you have (phone) is a lot better than what you know (password) and what you know (password2). Paypal has an optional 2-auth using an RSA dongle that generates a new unique key every 30-60 seconds. When you log in, you must also type in the code on your token or you are locked out.

Furthermore, saying that sending text messages are too expensive, that's ridiculous. You're talking about a client's money, not some shitty web service like porn, or games. I don't know how much SMS services cost, but I do know a lot of websites offer the ability to send messages for free (no idea if there are strings attached).

What are the risks? I'm thinking of essentially cloning my bank's system, which works like this: I get a list of keypairs from my bank, maybe 100, maybe 300 of them. The bank's on-line services ask for a random keypair from this list when I log in, and each keypair is only used once.

The list comes with a serial number, and has been activated for use by the bank before they sent/gave it to me. When I have 10 keypairs left, the bank's online service tells me I need to start thinking about getting a new list of keypairs. Once I have the new list, it must be activated. The bank's site asks for the serial number of the new list and a keypair from the old list. (Better still have some keys left on the old list!)

The main risks, as I see it, are: someone intercepting the list of keys as it's being delivered to me and someone gaining access to the list when I have it. The risk of interception should be mitigated with standard security methods you'll need to use anyway (ssl, for one), while keeping the list secret is a problem you'll have with a phone as well. The list doesn't actually need to be printed anyway, I'd probably store mine encrypted somewhere.

Is there some risk I'm missing?

I'll describe the architecture of this system as I see it, for my reference and others to comment:

Exchange webserver

Stored in database (encrypted using user's password):
- secret key (seed)
- one time passwords for account recovery

Tools used for authentication:
- google-authenticator slightly modified binary provide by Google to accept username as an parameter and for non-interactive worflow (only outputs the data)
- auth-check, a simple tool written by me that uses libraries provided by Google to verify tokens for given account and secret key

User's device

- iOS, Android or Blackberry app, all managed by Google
- iOS and Android have a barcode scanner that simplify key input
- the app shows new time-based token every 30 seconds, which can be verified by auth-check module on the server

How the setup process will work:

- user enables 2-step authentication in his profile
- he is prompted then to download an app for his smartphone
- the site displays then the details needed to setup the device (account name and secret key) AND a QRCode to make the process quicker (if users device supports this)
- after this setup the device and sites are now paired. As an additional security measure a list of one time passwords is displayed and user has an option to print it (while hiding all other details) and save it somewhere safe.
- should the user lose or break his phone, he can use one time passwords to log in, deauthorize the phone and setup a new one

How the verification works:

- the user enters his credentials (username and password) as always
- when the credentials are ok, server decrypts the secret key using provided password and asks for the time-based token
- user opens the app on his phone, types in the 6-digit token and logs in to the site
- each token can only be used once. After sucefully using a token no one can reuse it, even if the 30 second period didn't pass yet

-------

Potential risks

For this system to be broken, several conditions would have to be met:

- exchange database compromised
- user's computer is compromised / user's password leaks from other site

OR

- user's computer is compromised
- user's smartphone compromised

OR

- user's login details leak from some other site
- user reuses password AND username on both sites
- user's smartphone compromised

While these are theoretically possible, the probability of these events are significantly lower than just one of these happening. That's why I think a system like this should be a part of every exchange / Bitcoin handling site.

Cool!

I've decided to go with the Google auth option. It seems very easy to implement (as a matter of fact I have already built a sample implrmentation). And it has good iOS and Android clients.
I will report how it went .

I'd say so, yes.

So to conclude your discussion - mobile app is most secure of it all, because even if your whole computer gets compromised, one could not access your account when using 2-factor auth with mobile app. Of course this mobile could be compromised too, BUT it couldn't be tied to any account easily (because the app only stores a seed, and not an account name). So defeating that would be VERY hard (not impossible, but not feasible either).

For the same reason email tokens don't work.  If they hacker compromises your system "what you know" is no longer a valid form of authentication.  And since they have access to your system they can also nab your private key. <3

I am not disputing that the security levels are different with different methods, and one has to assess what level would be acceptable in a given context.  What I am disputing is your bizarre claim that PGP/GPG signing/verification of a unique token isn't a valid second factor authentication.

Cheers,

Yes, but I don't enter my password on my phone.  So the hacker would still need to get that. <3

Again: come on, dude — there could be malicious apps on your phone, too.  This doesn't make it less a 2-factor authentication method, it just implies a different security level with different methods.

Cheers,

Most "software" keyboards send the same signals to the OS as if you were using a hardware device, hence it will be logged.

I could use a virtual keyboard to enter the passphrase with e.g. the mouse.

I can agree that using PGP/GPG as the second factor is probably less secure than e.g. a mobile app, and if you think it doesn't meet your security level requirements, you shouldn't use it, but I strongly disgree that it cannot be used as a second factor in authentication.

Cheers,

You are entering it with a keyboard no?  Then software can log it.  Given enough time and resources your solution falls if the hacker gains access to your machine.

Come on, dude.  My GPG private key is protected by a long passphrase that I haven't stored anywhere except in my brain circuits.  There's no way an intruder could sign a unique challenge with my private key (except threatening me physically to disclose it, but he could do the same with your PIN).

Cheers,

http://en.wikipedia.org/wiki/Keystroke_logging

Then he has to get past a 3rd factor, my pin.

(I don't store passwords on disk, so a hacker wouldn't have access to my password.)

And if the hacker has your phone, he also pwns your OATH app == 2nd factor requirement not met, using your logic.

Cheers,