A plea to exchanges ... lets do 2 factor right!

[DeathAndTaxes]

Having 2 factor checked only at login is a security issue.  Please consider following MtGox's lead and properly secure withdraws with an explicity authentication.

Having 2 factor at login is "good" (certainly better than no 2 factor) but it still leaves the user vulnerable to session jacking where the attacker can impersonate the already authenticated user.  For sites that allow 2factor to be disabled from an authenticated session without a final 2factor verification a simpler attack is possible where the attacker simply disables 2factor from an active session and locks the user out.

Example session jacking attack:

User who has a strong password and OATH (2factor) device logs into exchange.  User is prompted for 2factor code, and authenticated.  Unknown to the user his system is compromised and is monitoring browsing activity looking for logins.  The trojan notifies the attacker that the user has an authenticated session.  Attacker uses the trojan and authenticated session to exchange all USD for BTC and withdraw all BTC to attacker's address.  This action can be nearly invisible to the user.   The user's session is stolen and the attacker impersonates the user when making the withdraw.  To the exchange server everything appears as genuine browser actions from an authenticated user from their IP address.  The speed of the attack is only limited by the exchange servers processing.  The user can be logged in looking at $18,000 USD and 2,000 BTC and then an AJAX refresh occurs and user is looking at $0 USD and 0 BTC. Looking in the activity history the user will see trades and withdraws that occurred seconds prior which appear to have come from him.

Eventually this WILL happen; it isn't a matter of if but when. When that happens it will undermine confidence in users.  "See even WITH strong passwords AND 2 factor AND a reputable exchange with partial cold storage you can still lose everything in a second".  

MtGox's setup with a complete security center and ability to configure multiple OATH devices for various options is ideal but it is also a lot for a smaller exchange to take on.  

The simplest fix (more like a patch) is to just limit 2factor to withdraws (and removing/updating 2 factor and editing/adding pre-saved withdraw options).  Obviously changing 2factor should always require 2 factor verification.  While in theory if 2factor is limited to just withdraws an attacker could force a user to sell (and attacker ensure he has the highest bid) however max loss would be the % difference in the bid ask spread.  (i.e. user sells $1,000 worth of BTC and only gets $997 worth of USD).  It is a pretty weak attack vector and certainly less profitable than session jacking.  The largest attack vector is removing funds from the exchange account moving the 2factor to that action hardens it.

A better solution would be to have multiple choices on 2factor configuration page.

• No 2 factor
• 2 factor on withdraw
• 2 factor on login
• 2 factor on login & withdraw

[Marco Polo]

It would also prevent unauthorized withdrawals done with stolen cookies using XSS bugs or MITM (for example in public wlans)

[Stephen Gornick]

however max loss would be the % difference in the bid ask spread.  (i.e. user sells $1,000 worth of BTC and only gets $997 worth of USD).  It is a pretty weak attack vector and certainly less profitable than session jacking.

Well, with no OTP on login or a jacked session it is not unfathomable that the account could be used to trade away all the funds from the account over a series of trades versus being unable to withdraw due to that being protected with OTP.  

That could have been the real reason there was this "algo freakout" a couple months back:



 - http://bitcoinmagazine.net/wp-content/uploads/2012/08/bot-runs-amok-on-mtgox.png


There's  list of the two-factor authentication methods the different exchanges offer here:
 - http://bitcoin.stackexchange.com/a/4114/153

If there are additions or corrections, there is a comment facility for those registered or PM me here on the forum.

[nedbert9]

Completely agree with D&T.  Client-side and account transaction-level security is an afterthought for too many Bitcoin services.


The common answer for account hacks is far too often 'Your fault, your problem, read the ToS.'


A wider audience will hold a service responsible in their minds if that service doesn't represent the best interests, e.g. security, of their accounts.


By the way.  There are tickets open with GLBSE that their 2FA isn't working.  I've personally experienced issues where MtGox's 2FA had a glitch and wouldn't challenge for 2FA.  Various service sites where session token expiration periods number in days - not hours or minutes.  

Unlikely shouldn't be the key measure of security.  Security best practices for financial web apps should rule and that isn't the current state of affairs.

[DeathAndTaxes]

Well, with no OTP on login or a jacked session it is not unfathomable that the account could be used to trade away all the funds from the account over a series of trades when withdrawing is protected with OTP.  

You probably are right and I likely understated that risk.  Still the far easier and more direct attack is to simply to withdraw the funds.    Not requiring OTP on that highest risk transaction is a vulnerability. 

For highest security OTP should be on both the login and withdraw.  Optimally the user should be given the choice. Still if an exchange had limited resources offering OTP only on login is worse IMHO than offering it only on withdraw.  The reason is that OTP on withdraw means 1 OTP = 1 withdraw.  Having it at login means 1 OTP = unlimited access to site including withdraws until session expires.

Security is always a tradeoff; an exchange could require a unique GPG signed message for every user actions (login, trade, cancel trade, change info, download history, withdraw, etc). Most users would not want that level of security.  So the goal becomes the most security for the acceptable amount of complexity.   The withdraw is the point of highest vulnerability.  If an attacker can withdraw BTC, he can steal quickly and with little chance of getting caught.  That action, having the highest risk of being fraudulent should require explicit (not implicit from the session login) authentication.

[ArticMine]

...

Well, with no OTP on login or a jacked session it is not unfathomable that the account could be used to trade away all the funds from the account over a series of trades when withdrawing is protected with OTP.  

...

Or to manipulate the market by trading in a particular direction using a series of compromised accounts. Two factor authentication is certainly part of the solution.

Another is to mitigate the risk of a compromised system by avoiding operating systems that are the major targets of malware such as Microsoft Windows. I have been using GNU/Linux (Ubuntu)  for this very reason for all my secure transactions / logins /applications for over six years for this very reason. Today I simply refuse to do anything involving Bitcoin or fiat banking using Microsoft Windows.

[DeathAndTaxes]

As Bitcoin continues to grow in popularity that is an unreasonable demand.  It may be a good practice to personally protect your wealth but an exchange should expect that a portion (probably a majority) of its users are logging in from a Windows machine.  I would point out that session jacking isn't just a windows issue.  There are exploits in MacOs, iOS and Android OS as well.  Users logging in from public wifi risk MITM attacks regardless of the OS.  Cross Site Script vulnerabilities in browsers, extensions, and plugin (java) are generally speaking OS agnostic.

[firefop]

Really the only way to make this overly secure without being annoying to the average user is by a third party service to 2fa (such as phone factor). Of course using an existing service will incur costs - and managing those will come out eventually in the exchanges rates.

IMHO - a better solution would be to leave the security in the hands of the real users aka technophiles who like us who can handle it ourselves. While developing a POS or general access system that's hardware based and secure via the hardware.

can you say "hardware bitcoin that stores your private key + biometric scan for 2fa at point of sale" --- And yes, I'm planning on developing it =P

[ArticMine]

As Bitcoin continues to grow in popularity that is an unreasonable demand.  It may be a good practice to personally protect your wealth but an exchange should expect that a portion (probably a majority) of its users are logging in from a Windows machine.  I would point out that session jacking isn't just a windows issue.  There are exploits in MacOs, iOS and Android OS as well.  Users logging in from public wifi risk MITM attacks regardless of the OS.  Cross Site Script vulnerabilities in browsers, extensions, and plugin (java) are generally speaking OS agnostic.

I for one am for a web based business supporting as many different platforms and operating systems as possible, so I would never expect a web based business to not support Microsoft Windows. As the owner of a website for over 10 years most of my visitors use some version of Microsoft Windows. In fact this year I even got the odd visitor using Windows 3.xx! Having said this it is also very important to be honest about the risks involved. We are talking about risk mitigation not risk elimination here. Sure there is the odd piece of malware for GNU/Linux or cross platform browser exploit, and some exploits by their very nature are cross platform such as phishing attacks, MITM attacks etc, but the reality is that a lot of attacks here are Microsoft Windows specific and can be eliminated by simply not using Microsoft Windows. I have for example removed Windows specific Bitcoin stealing and mining malware from a customer's computer. The customer had never even heard of Bitcoin!

Where this is important for an online business is to ensure that the site is compatible with GNU/Linux and that any two factor authentication security methods used dot not exclude the use of GNU/Linux and other Free Software operating systems. I would take single factor authentication on a properly secured GNU/Linux system over two factor authentication on Microsoft Windows any day from a risk mitigation perspective.

[DeathAndTaxes]

Really the only way to make this overly secure without being annoying to the average user is by a third party service to 2fa (such as phone factor). Of course using an existing service will incur costs - and managing those will come out eventually in the exchanges rates.

There is no requirement for a third party service.  Almost every exchange support TOTP which can be implemented without any third party service. http://tools.ietf.org/html/rfc6238 Of course that ignored the point of the OP which was that OTP leave the user vulnerable to session jacking if the user is only authenticated at login.

[firefop]

Really the only way to make this overly secure without being annoying to the average user is by a third party service to 2fa (such as phone factor). Of course using an existing service will incur costs - and managing those will come out eventually in the exchanges rates.

There is no requirement for a third party service.  Almost every exchange support TOTP which can be implemented without any third party service. http://tools.ietf.org/html/rfc6238 Of course that ignored the point of the OP which was that OTP leave the user vulnerable to session jacking if the user is only authenticated at login.

That's exactly why we need live 2 factor authentication... using phone factor as an example again. . .

Any time there's an auth attempt the thing calls you so you can verify by entering a numeric code. A session jack wouldn't matter at that point, because when they tried to do anything the phone would ring.

That's what I meant about a 3rd party service - in this case using the phone system as the second factor. maybe voip using voice recognition could work in a simular way without having to involve a telco?

[Mosrite]

This is a real concern. I am going to ask Byron Micon to suggest a workaround.

[markm]

For the trojan case in the original post, what stops a trojan for waiting until the user is ready to commit a withdrawal and changing the address the server ends up being told to send the withdrawal to?

Also, I thought the whole point of two factors is that both factors are so distinct and separate that if only one of your machines is controlled by the attacker any action that requires the second factor is pretty much beyonf the attacker's ability to authorise?

For withdrawals presumably this means once a withdrawal request has been submitted the second device is contacted by the server with details about the transaction requested, and the user must confirm with that second device that the request is indeed the one they intended to make?

-MarkM-

[firefop]

For the trojan case in the original post, what stops a trojan for waiting until the user is ready to commit a withdrawal and changing the address the server ends up being told to send the withdrawal to?

Also, I thought the whole point of two factors is that both factors are so distinct and separate that if only one of your machines is controlled by the attacker any action that requires the second factor is pretty much beyonf the attacker's ability to authorise?

For withdrawals presumably this means once a withdrawal request has been submitted the second device is contacted by the server with details about the transaction requested, and the user must confirm with that second device that the request is indeed the one they intended to make?

-MarkM-

That's how I understand it.

And I suppose you could attach an IVR to the front on the phone call telling you things like amount, destination address etc - that might be annoying but it would address the change of destination address you've suggested.

[DeathAndTaxes]

For the trojan case in the original post, what stops a trojan for waiting until the user is ready to commit a withdrawal and changing the address the server ends up being told to send the withdrawal to?

Also, I thought the whole point of two factors is that both factors are so distinct and separate that if only one of your machines is controlled by the attacker any action that requires the second factor is pretty much beyonf the attacker's ability to authorise?

For withdrawals presumably this means once a withdrawal request has been submitted the second device is contacted by the server with details about the transaction requested, and the user must confirm with that second device that the request is indeed the one they intended to make?

-MarkM-

It really depends on how much you want to lock it down.  One option would be to make the withdraw screen only allow withdraws from a predesignated set of addresses.  Adding an address require a 2factor check and a time delay.  User could also be notified and sent an SMS with the address being added.  That way an attacker would be unable to substitute the withdraw address as the user at time of withdraw is limited to a pre-validated list of addresses.

Another simpler option would be to delay withdraws by say 15 minutes and send the user an SMS message with the address.  If user notices the address is invalid they could cancel the withdraw within the 15 minutes period.


BTW: I have no idea what firepop is saying.  He miss to miss the entire point.  The method of 2 factor isn't what matters.  A voice 2factor service is no more secure than a TOTP.  It is HOW it it used.

[firefop]

Agreed. 2nd factor type shouldn't matter much, only how its implemented.

[burnside]

Absolutely agree with the OP.

LTC-GLOBAL / BTC-TC both allow the user to turn on Google Auth for login plus all financial and share trading transactions, including protection against replay attacks.

Hopefully I can pick up a yubikey soon so I can play with that as well. 

Cheers.

[J-Norm]

I would really like to see a system whereby any transaction on an exchange involves the server giving you a programatically defined contract(Send 150BTC to <someaddress> from my account) and then requiring you to sign it with your GPG key.

We have a high grade cryptographic signing system and I have seen it being used exactly once.

There is a project called bitwasp that will provide a "silk road like" website that anyone can run, but it supports requiring GPG signature for any sensitive action.

Not that user friendly, but if it is optional the more savy folks can really protect their accounts.

[burnside]

I would really like to see a system whereby any transaction on an exchange involves the server giving you a programatically defined contract(Send 150BTC to <someaddress> from my account) and then requiring you to sign it with your GPG key.

We have a high grade cryptographic signing system and I have seen it being used exactly once.

There is a project called bitwasp that will provide a "silk road like" website that anyone can run, but it supports requiring GPG signature for any sensitive action.

Not that user friendly, but if it is optional the more savy folks can really protect their accounts.

I had a discussion recently with someone here about GPG security vs. 2FA.  I'm not sure that GPG is as good as some of the other 2FA approaches, because you have to keep your key offline for it to be secure.  With the PITA factor people end up keeping their key on their desktop, where if you're compromised and a keylogger is installed, you're screwed.

The 2FA with Google Authenticator, Yubikeys, etc., seems to avoid that particular mode of failure at little to no expense in terms of ease of use.

Dunno... is there something I'm missing?

[J-Norm]

GPG keys are the basis of the otc web of trust as I have very recently learned. Neat idea.

I know how to protect a gpg private key, I can keep the CIA, FBI and the whole alphabet soup from my gpg private key.

I agree people who don't understand just how private a private key must be guarded should not activate this advanced feature. But I don't have a non-encrypted storage device in my house.

Bitcoin itself depends on protection of private keys.

I am confident that I am the only one loggin in if:

• I must enter a password
• I must sign a 256 bit string of bytes using my registered key

I would of course have a password for that key that would never be defeated by a dictionary attack.

I think you should be able to configure just how locked down your identity should be from simple to cryptogeek.

Consider smart devices already exist that will use a private key for you but no reveal it. Chip-Pin credit cards use them. "Smartcards" can do this. Now you can use a bit of plastic with a built in signer, or a laptop, or a server cluster, or your smart phone.