Topic: A plea to exchanges ... lets do 2 factor right! (Read 5601 times)

What is your opinion on how safe your private key is on the chipped cards, smart phone apps, etc?

How do you keep your key secure from a virus on your system?  I understand keeping the storage encrypted, but you have to decrypt the storage to use it, at which point the virus can also read it, no?

I think at one point MPOE-PR mentioned using QR codes to securely pass messages back and forth between an offline device and an online device, are you aware of any products that might facilitate this?  (I'm thinking cell phone apps?)

Sorry about the 20 Q's.  You seem pretty knowledgeable so I'm picking your brain a bit.  

This is a great idea. Not only can people use it to limit a grab and dash by some theif but it could also be used to enforce a budget on yourself.

Also, much must they invented time lock on vaults so that bank managers would stop getting kidnapped in the night you could set it up so that you only have access to funds during hours you know you will be safe.

I decide on a budget for a week and I spend it in 3 days. I dream of a machine that will give me money by the hour based on my weekly budget.

I spend like a fool.

TLDR; 2 factor authentication is available in a lot of formats

Self-imposed withdraw limits may also be a good idea, and perhaps more convenient to some. Any attempt of changing these limits should required 2-factor-auth or at least produce a notification, and the change should only be applicable 48h later or something.

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.

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?

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 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.

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.

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

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.

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.

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-

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

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?

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.

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.

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

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.

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.

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.