Bitcoin Forum

 Attention:  Mt.Gox, TradeHill, MyBitCoin, and all other bitcoin services!

Here is an idea for an easy way to add optional 2-factor authentication to logins.

Two-factor authentication is a more secure way of allowing access to a user account.  It uses two separate channels to ensure that the user is who they say they are.  Typically, it uses something they know (like a password), and something they have (like an RSA key fob).  The problem with key fobs is that you have to pay for the third-party hardware gadget, and distribute them to users, which gets complicated.

The simple alternative I'm suggesting is this: allow the user an option to use 2-factor authentication based on a 260-character "passcard" that the user provides, which is then used at login to issue a challenge-response PIN identification.

 https://secure.wikimedia.org/wikipedia/en/wiki/Two-factor_authentication (https://secure.wikimedia.org/wikipedia/en/wiki/Two-factor_authentication)
 https://secure.wikimedia.org/wikipedia/en/wiki/Challenge_response (https://secure.wikimedia.org/wikipedia/en/wiki/Challenge_response)

Here's how it works.

(1) To set up my 2-factor login, I send you a string of 260 symbols, to be interpreted as a passcard with 10 rows (0-9) and 26 columns (A-Z).  You store that safely, like you do (hopefully) with passwords.  This passcard information is communicated only once, when I'm setting up the 2-factor login (much like setting a password).

(2) Now each time I login, you include a request for a 4-digit PIN, starting at a particular row and column (generated randomly).  For example:


The key point here is that a hacker (say, hypothetically, in Hong Kong) won't have access to my passcard, and can't login as if they were me, even if they've cracked my password.  [Added bonus: kills bots dead.  No need for annoying CAPTCHAs if they've opted for 2-factor login.]

For my part, I can create my 260-symbol passcard in whatever way I want.  For example, I can use the Python code below to convert a strong passphrase into a passcard block (maybe on a different computer, just to be extra safe).  Now I can print out the passcard, put it in my wallet, and erase all traces of its creation.  If I ever lose the card, I can easily re-create it from the passphrase.  (Python uses the Mersenne Twister RNG algorithm, so it will always generate the same sequence from the given seed).

Or, if using that piece of paper is too cumbersome for me, I might decide to have a .jpg image of the passcard on my phone, or whatever other reference method I'm comfortable with.  [Or, if I'm not too concerned about someone gaining full access to my computer, I could even have it on my desktop, or have a password manager that answers the challenge-response PIN for me.]






People: If you want to use this code to create a passcard, go ahead.

Businesses: If you want to use this code to help your users create their passcard, please ask me for permission first.  Regardless, do allow them to submit *any* block of 260 symbols that they choose.

Note: I do not suggest using a card like this for all of your passwords, because it is a single point of failure, and only provides a relatively small number of possible passwords.  (It would be better than reusing the same weak passwords, however).  As a second channel for authentication, it seems okay.

For some more fun facts on password cracking (and on the Mt.Gox hack in particular) see my previous post:
http://forum.bitcoin.org/index.php?topic=24727.msg314393#msg314393 (http://forum.bitcoin.org/index.php?topic=24727.msg314393#msg314393)

Disclaimer:  I'm a math and algorithms guy, but I don't know very much about computer security or cryptography.  This whole idea might be horribly broken.  If it is, then please explain why, so that we can come up with something better.

This is what I love about the community. People working together to make it a better place.
I'm not one of the coders so I can't say how well we could implement this in to our site.
We will be announcing our 2 factor authentication soon though. We've been evaluating and testing it for a while.
We don't want to release anything that isn't ready to go and well tested.

Thanks for the quick response.  Glad to hear that it is already on your radar.

If you're thinking of using a smartphone app, or something like that, then I encourage you to consider having more than one option for 2-factor authentication.

I haven't seen something like my method offered before.  It's dirt simple, doesn't require any special equipment or technology, and is completely under the user's control.  Implementing it would not be very different from handling passwords now.

Our solution has a few ways to authenticate but yours would be a lot cheaper if we can implement it. Naturally that's a plus. We're not opposed to paying a lot of money for security if needed but if we can be nearly as secure without spending five figures it would be an easy choice. We're concerned with ease of use and simplicity for the average user.

I'll promise that we will look in to it and will have a 2 factor authentication ASAP but not being a coder I can't promise anything more than that at this point.
-Jered

Well, those who opt for 2-factor logins generally aren't average users, by definition.

But it is very easy to use in any case -- much easier than conventional methods, like Google's.

They just copy-n-paste their 260-symbol block into a password field.  Or, if they prefer, they can let you generate a passcard block and send it to them (maybe with a nice colourful image, or pdf).  The fact that the system is uncomplicated makes it easier to design a clean, elegant UI.

Regardless, thanks again for discussing it with your team.

relies on sending the one time pad to the user, which evil eavesdropper could intercept and use to login from that point on.

this is the problem with a shared secret, and why public key cryptography, which allows a shared secret to be securely exchanged between two parties without an eavesdropper being able to determine it, is used nowadays.

The more secure cryptographic equivalent of your idea is to issue the user a client certificate, and for them to store this client certificate in a secure password protected certificate store.  I think one exchange is doing this already.

Will

What a brilliant idea. The only flaw I can see here is if the passcard, (which would need to be stored in a db somewhere) were compromised along with user login information.

Yes, if the site is storing the information insecurely, like MD5, then the user is still hooped.

True, this does not provide a 100% secure alternative.  It is a quick-n-dirty alternative that provides a little less than 100% of the value, in exchange for a lot of practical benefits.

Maybe it shouldn't be called 2-factor authentication, to avoid any possible confusion.  Maybe it should just be called something generic, like "extra password protection", with no theoretical guarantees. (*)

I do think the benefits are significant though, since almost all break-in attempts will occur afterwards.  The fact that some 15-year old h4ckzorz in Minsk can't be taking pot-shots at your account password seems to be worth something...

(*) "In theory, there's no difference between theory and practice.  In practice, there is."

http://www.duosecurity.com/

2 factor auth services.

Sorry, but this idea has the same vulnerabilities as the rest.

Nice find. I snapped that up for my own use. :)

Wouldn't the easiest two factor login for Bitcoin not just be to make use of Bitcoin's intrinsic cryptographic values:

On registration you give a bitcoin sending login address you own to the service provider, for example 13Ycm33vMGUo2HCu87pXZtqNapx8Cjjhb1.  To confirm that it is actually you attempting to login, the service provider gives a four digit random number , for example 5783 (wxyz with w=5,x=7,y=8 & z=3)- and he confirms your identity on 0/ confirmations when you've sent 0.015783 (0.01wxyz) to the service provider's associated address for your account FROM your bitcoin login sending address (registered for login purposes and on file with the service provider), ie. 13Ycm33vMGUo2HCu87pXZtqNapx8Cjjhb1 .  The service provider confirms from the blockchain that you did sent 0.015783 (0.01wxyz) from your address on file with the service provider, ie. 13Ycm33vMGUo2HCu87pXZtqNapx8Cjjhb1 , and allows you access (because as the owner of 13Ycm33vMGUo2HCu87pXZtqNapx8Cjjhb1 only you should be able to actually spend from this address).

Please note that both transfers for login purposes can be sent without transfer fees as they exceed 0.01 btc minimum.

It seems like Bitcoin after all has some other useful uses than just a medium of exchange!

There's no real way right now to send coins from a specific address. Not to mention that the address might not have any coins anyway.

That would be BTC 0.01, right?

Cheers,

"Looks" nice, but you'd always have to rely on this third-party. A really secure alternative would be this: https://www.privacyfoundation.de/crypto_stick/crypto_stick_english/ (or generally any other smartcard-based authentication). Major drawback: relatively large one-time cost (49€ for the crypto stick, even more for smartcard + reader).

There is - you just spend all your coins in your wallet to a certain address in your wallet that you own and it consolidates into the destination address and empties all other addresses.  You can also have a dedicated wallet.dat just for this purpose if you do not want to mess up your other keys.

OK, then you either have to wait to spend any more bitcoins, or pay a transaction fee. Or wait hours for it to be confirmed. As an authentication method, this certainly doesn't seem workable.

I'll correct, thanks!

The cost in bitcoins of the 0.01wxyz btc login pin 0/? confirmation scheme would be zero as the 0.01wxyz btc gets transferred to the owner's own account at the service provider anyway (the owner of the bitcoins being the service user attempting to login by transferring the random agreed number of bitcoins).

But regardless, at worst 0.019999 btc = ~0.29US$ at present, and 0.010000 btc = ~0.15US$.

This number of bitcoins can however be transferred back to any address the owner likes as it has remained his property - it is just temporarily used to verify ownership of an address on file with the service provider (and thus verifying account ownership - whether anonymously or not).

One-time-passwords don't need to be that strong.

The cheapest way is to periodically print out and mail sheets of indexed TAN (http://en.wikipedia.org/wiki/Transaction_authentication_number) to the user. Make it four digit index and six number passcode or something like that and it's plenty strong and still easy to use.

Never really saw the need for electronic gadgets to do the above.

International mailings are slow, expensive and barely reliable. This is something your local bank might be able to do, but not Mt. Gox or Tradehill.

With the 0.01wxyz 0/? confirmation bitcoin login - only the user owning the username knows what wxyz the service provider requires (displayed in https),

and

Only the User owning the username can send the 0.01wxyz number of btc from the associated address to his account with the service provider (he owns the wallet.dat and only him can send from the associated address)



Thus ensuring trust with the Bitcoin network at no cost - to enable trusted second layer login in addition to username, password combinations.  The waiting time should not be that long for the 0/? confirmation to propagate through the distributed/decentralized bitcoin network from the user to the service provider - mostly instantaneous.  Double spending is not of importance in this instance.  The balance of the user's account with the service provider can be adjusted only after more confirmations, enabling the user to transfer the random bitcoins again for other uses.

While the idea that only the owner of the wallet can send from said address sounds nice, I'm sure this will cost endless grief in real life.  For one thing, users of online wallets cannot use this system, and users that have their own wallet really have to know what they're doing in order to send from a certain address.  It may be secure, but certainly not user friendly.

Cheers,

Here comes the opensource implementation bitcoinjs (webcoin), a webbased java client to the rescue , allowing bitcoin webservices where you keep your eeny, weeny, tiny kilbytes wallet.dat file on your local machine and separated from the gigantic, bulky, chunky, monstrous soon to be gigabytes blockchain file which is now for this service kept centrally on a server (and this centrally kept blockchain can be verified against other sources of the blockchain for the paranoid).

I am posting this on behalf of dsp(http://forum.bitcoin.org/index.php?action=profile;u=31526 (http://forum.bitcoin.org/index.php?action=profile;u=31526)) a newbie who is restricted to the Newbie forum:

Original post is here: http://forum.bitcoin.org/index.php?topic=26124.0 (http://forum.bitcoin.org/index.php?topic=26124.0)

I would like to see more federated authentication (OpenID). Then, whether we authenticate with PGP or mailed TAN, we can use the same authentication token for many services in the bitcoin community. Services like OpenID haven't taken off due to the chicken-egg problem. Well, we're a huge clutch of chickens! let's lay some eggs.

I'm making an app on google's appengine and was considering using OpenID for user authentication....researched it quite a bit, but openid on appengine dont work with https... so that kicks that idea to the curb for now.

Google's own implementation of openid works on appengine https, but you require a google account....and I'm not sure everyone who uses my service would accept that....but i might go that route anyway due to the complete ease of implementation and the fact that all the messy bits are taken care of by someone else.  If true openid over appengine's https becomes available, i could then easily add that....but for now, a google account is required afik.

I bet at least 50% of my potential users would run away if they needed a google account to log into my site.  What do you think?

Let us not call Google or Facebook authentication OpenID. They both are OpenID providers, but not consumers. No one wants twenty disparate OpenID's. Users want one (or many that they have 100% control over). In other words, Google and Facebook will let you login to other sites with your Google or Facebook id, but neither will let you login to their own sites with other identities.


As much as I like Google, using their authentication method for money gives me the willies. Depends on what your plans are. Maybe it's just a proof of concept and you can take it from there.

i like my Yubikey  :)

Oops, dsp sent me his link, but I didn't understand that he couldn't post it, due to his n00bie status.


Also, jaakkop (http://forum.bitcoin.org/index.php?topic=26124.msg326768#msg326768 (http://forum.bitcoin.org/index.php?topic=26124.msg326768#msg326768)) mentions this tool from Google:

  http://code.google.com/p/google-authenticator/ (http://code.google.com/p/google-authenticator/)


Another passcard service I found, with an open source algorithm and mobile support is:

  https://www.passwordcard.org/en (https://www.passwordcard.org/en)

On topic, csshih posted this to the Trading section:

  http://forum.bitcoin.org/index.php?topic=26385.0

Mt.Gox is introducing Yubikeys (a USB device for 2FA), currently in beta to ~50 users.  They will be making them available for purchase for $30 (BTC accepted, naturally).

The bashers can't bash that!

I Love the smart phone app id ....

I think the odds of guessing the next random number from a smart phone is going to be rough ...

why can't I have a app that app on my smart phone app that sends a random number to mt gox or tradehill (only good for 3 mins) that I have to enter in to the site to login

Not sure how that would solve a database hack (like at gox) but would require someone to break the password and  have the verified cell phone (over sms, an android app could watch for it in setting up the phone the first time)

It would allow me to not have to buy some key, and what happens when I lose/break the key ?

The problem with this method is that if you are sending this information over the internet then it has failed since most trojans record all HTTP traffic

Over https?

I have used that before, works well.

Theory versus practice.  In theory, you're bugged all the time, forever.  In practice, there is a notion of before and after.  Yes, if you caught my code when I sent it, then I'm no safer (and no worse off).  But if you came along *later* and started snooping around my computer, then I am safer.

More to the point, if you are in Bulgaria taking shots at my password (or if you got your hands on the password database and eventually cracked my hash), then you still can't log into my account.  (Unless you also crack my 260-symbol random passcard -- good luck with that).

I'm not sure why practical measures like this are given little or no weight by the security community.  They always seem to be seeking the perfect system, rather than looking for simple practical improvements.  However, I freely admit that I don't know all the issues, so maybe they have very good reasons for taking that approach (like, having been burnt so many times in the past).