I think Amazon.com has a similar authentication scheme, where lots of stuff is accessible while logged in, but destructive stuff, like making a purchase, requires another log-in. It's a great model, especially when you think of it more like keeping safe things easy rather than making dangerous things hard.
I'd like to see more authentication frameworks take this use case into account. "Logged-in" should actually be a spectrum of at least 3 states, not binary.
The really secure version of this is a method used by some banks (eg, all German banks) where your normal login is basically read-only, and any action requires the use of a one-time code.
It can be a bit of a hassle, but it makes a lot of sense when dealing with money.
This requirement of extra security has forced thieves to develop more advanced methods. The easy stuff is malware that intercepts the PIN when you submit it on your desktop, and malware that intercepts SMS PINs can be found in many european mobile apps. The only practical use of 2-factor is to fight password reuse.
So really, they should just ask for a PIN once instead of for every action. But I bet it makes people feel more safe to keep entering it.
Not true. My bank in Switzerland uses the following scheme:
- For logging in, I enter a 6 digit code to the dongle. It spits out a 8 letter pass-phrase, which I then enter to the website.
- For authorizing payments, I need to enter the last 5 digits from the account number to the dongle. Again it produces a passphrase.
- The authorization is only required the first time you make a payment to an account. So it's not even particularly annoying.
This is basically malware-safe, assuming a user who understands how the scheme works. The result from a 6-digit input code is useless to an attacker, and no amount of malware on the computer can make me enter a 5-digit code (since I'd read those numbers from the paper invoice). Likewise highjacking form submission and changing the account number when I enter a payment would do the attacker no good.
The malware only needs to monitor your session until you enter whatever credentials were prompted of you by the real-live site, upon which it captures the connection, prevents your post, and does an automatic drive-by withdrawl from your account.
Phishing is a different discussion. For users who don't know better (which is 99% of them) they will just ask you for whatever they want, with a carbon copy of the content of the real site, and once provided with it, will do whatever one-time transaction you would have done on the real site. The only difference is they don't need malware to do this.
Combine the two (perhaps with some slight-of-hand using your own browser's UI) and they can challenge and authorize a payment to an account you don't realize is incorrect. If you double-checked the account number you might realize the switch.
For most American banks none of what you described is offered to the consumer or business owner. In Europe there's just an extra step in the way for the fraud. (Swiss bank accounts would, I assume, require more stringent security procedures than most other banks)
I don't understand where you think the attack surface is, and thus can't address the problem you think exists. So unfortunately the best I can do is describe the thing again, using different words. Sorry.
The posited malware can't initiate an automatic transaction, since an OTP from the bank dongle is needed. The dongle needs to be seeded with a specific part of the receiver's account number, so just any OTP generated by the dongle won't do. The account number has been passed out of band (generally on a paper invoice), so taking control of my browser doesn't give the attacker a way of fooling me into generating an OTP suitable for use with their account either.
The posited malware can't initiate an automatic transaction, since an OTP from the bank dongle is needed.
This attack hinges on intercepting a human entering in authentication information by hand into what they think is a secure, valid site. The human will be doing manual stuff, but the code is automated.
The account number has been passed out of band
If it was not passed out of band, or a phishing or mitm attack changes the account number and the user doesn't notice, this attack will work. It's a difficult but rewarding targeted attack similar to those used by the chinese, eastern europeans, etc.
One way is to use a generator that.. (who would've guessed that) generates the tan, another one (though no longer in use at most banks) are indexed tans – a list of one time codes that is enumerated. you are then prompted to enter "code 71" or something, you're getting the idea. the third, and currently widely used variant is mobile tan, where the transaction number is sent to your cell phone, along with some additional information like the amount to be transferred. Further reading: http://en.wikipedia.org/wiki/Transaction_authentication_numb...
> "Logged-in" should actually be a spectrum of at least 3 states, not binary.
And there should be better messaging for that.
For the last year or so I've been amused and then frustrated by ebay having a "Welcome, username" message in the header, but requiring another login before I can do anything relating to my account. Just providing a login link in the header would cut in half how many clicks I have to go through to add something to my watch list.
To be clear, I believe Amazon's "I filled up my cart, let's check out now" re-authentication is a protection against Cross-Site Request Forgery. The point being, an attacker couldn't just send you a link, have you click on it, and you've now just accidentally purchased $3000 worth of questionably viable prescription medication.
