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,

In a compromised machine the hacker has access to both factors (password + private key)

I never said it was simple, just that it is a possibility.

How come you think it doesn't meet “the 2nd factor requirement”?.  The steps I see are:

 1. First you log in using the usual username/password combo.
 2. Before you're let into the account, the exchange presents you with a unqiue token.
 3. You sign the token with the previously agreed on key.
 4. The exchange verifies the signature and the token.

Cheers,

That sounds entirely complicated and doesn't meet the 2nd factor requirement.

OATH is the best beta IMO.  The google solution looks hacky.

iPhone clients (incl one that is open source).  There are others that support oath but they are tied into service providers that download profile information and aren't usable outside of their services.

Oath Token: http://code.google.com/p/oathtoken/
DS3 Oath

Link to “Two factor user authentication with Google Authenticator” HOWTO.

Another possibility is GPG/PGP authentication, much the way we do it on the #bitcoin-otc IRC channel.  When you enable 2-factor auth on an exchange you could upload the pubkey you wish to use.  When you have to authenticate yourself you have to sign and upload a unique challenge string that the exchange creates for the session.

Cheers,

Wow, I've did know that. Will investigate this option! Yes, they provide iOS as well as Android clients. Do it fits.

The Google Authenticator is available as a PAM module for use on unices.  I've been using it for SSH-authentication.  Works great with all programs that uses PAM — no need to code an Android app, as you can simply uses Google's (is there an app for iPhone?  I don't know…).

Cheers,

@rebuilder: I had a thought about paper lists, but as a fallback mechanism. Printing them on-demand would create a vurnability of its own.

Why complicate things with phones and apps? Just generate lists of single-use keypairs and let people print them out or store them in an encrypted container, whatever they want.

Not really. If the computer is infected this wouldn't help at all.
You need additional hardware like a phone, a token or a card reader to be secure.
My bank for example is sending a text message to my phone when I want to make a transaction.
This message includes the transaction details and a one time code.

At one point I have thought of this, but email proves to be not bulletproof on us lately. Some of the emails are marked as spam by some providers. So this could create more problems that it would solve. The solution for this would be a good service (SMTP server) for sending emails, with good, trusted SPF records and hopefully cheap. Anyone knows a service like that?

You could also implement 2 factor via email.  So long as users are not dumb enough to use the same passwords on their email and the service it would be fairly strong.  Steam started using this.

Another thing to consider is not requiring it for every login.  You could store a long(er) term cookie that authorized that machine for the account, encrypted/hashed ip address + auth.  This could reduce infrastructure costs of any solution you choose.

There also seems to be a lot of 2 factor systems that support OATH (http://www.openauthentication.org/).  There were serveral apps that supported this in the apple app store from a cursory glance.  It is also supported by yubikey (http://www.yubico.com/yubikey).  

I agree that this would be better, but it would be expiensive too. It would require to charge our users for this which is something we want to avoid.

Implementing a sms/text code would be better IMO.  A lot of people don't have access to phones with web access, and those that aren't smart phones are lolwebstandards.

In the light of recent events, I'd like to ressurect an idea I had a while ago to make BitMarket.eu even more secure - optional 2-factor auth. I was inspired by Google while thinking about this, because they implemented this with their Google accounts and I use it on a daily basis. And it works great. For those who don't know how Google's implementation work:

- First of all, this is all optional. You are not forced to use 2-step auth.
- When you enable 2-step auth, you have to authorize a device (your phone with special app on it) to use it
- Then, when you decide to log in, the device acts like a token (think SecureID from RSA) that gives you tokens valid for 30 seconds
- So to log in, you have to use BOTH your account password and a token from your authorized device
- There is a fallback mechanism for this - a list of one time passwords that you can print and hide somewhere safe. These will let you log in to your account and make some changes, should you lose or destroy your phone

So I'd like to ask you guys, what do you think of this? I'd like to mimic what Google does, with one exception - I don't want to make a native iOS/Android application, because it would take much time (and I don't own Android devices for testing it). Instead, I'd like to make a web application using HTML5 Local Storage, or even better, something like this to store the token seed. This way it could be platform independent and work for many more users.

I understand that this all could seem difficult and troublesome, but I guess for someone that has more than 10 Bitcoin on my (or your) website, this should be a must to protect his/her wealth.

Oh, and last thing. I am willing to do this work and open source it so every exchange/service can use it to make their website more secure.