AOL Moves Beyond Single Passwords for Log-Ons

ars writes "Yahoo is reporting that AOL is adding a new feature alowing customers to use two passwords to log on. The second password comes from a small small device from RSA Securitywhich displays a new password each minute. The scheme is called two-factor authentication and will cost $1.95 a month plus a one-time $9.95 fee. It's aimed at small business and people who conduct large transactions online."

Comments

And... I'f I don't need a password..at all..

[Demanche]

Can I have a $2 discount???!??!

^^ Average american reply if this gets implemented.

Have fun at the aol sales desk ;)

Not a bad idea

[Celt]

AOL/TW employee's use these so why not offer it to customers, imho if banks gave out these devices for a one-off-fee on-line banking would be ALOT safer and there'd be less scams.

Also sometimes those secure ID devices can go out of sync with the server and thats when the fun begins :)
Thats the only problems I've seen with them,

--

Re:This will make the problem disappear.

[JohnHegarty]

two points...

1) it only lasts 60 seconds
2) if used , it can't be used again until the minute is up

You can't copy a physical token

[morzel]

If I get into your PC, I can copy your certificate without you ever knowing it until it's too late.
I obviously can't steal your RSA token without you finding out pretty soon.

I Used AOL securID

[Apple Acolyte]

In addition to being used internally by AOL, securID was offered to some regular users who were targeted by hackers. Like an organization I work for. The securID token is smaller than the average pager, having no buttons, only a display with a string of numbers that would alternate every 30 seconds or so. The biggest shortcoming of the system is that the battery did eventually die, and there was no easy way to replace it. That meant the account in question had to be unbound from the token. And it took a long time to find a rep that could actually handle that request. (Not that that was too big of a deal, since my organization only kept its AOL account alive for legacy purposes.) In terms of use, however, the token was not obtrusive at all. No additional client software was required. Upon sign on, a securID window was presented prompting the user for the key. Otherwise, it was transparent.

The big question is, is AOL's true motivation for offering this to regular customers just to compensate for the service's renowned terrible security?

Re:Isn't there a much easier way...?

[virtual_mps]

Something I've waited for years and it never come--maybe someone can explain why: client-side SSL.

Because client-side security sucks. The push for personal certificates is to provide non-repudiatable authentication. Think about that for a moment--do you want your identity tied to something sitting on your home computer? Something that, once taken, could provide access to your bank accounts, credit, medical history, etc.? Something that, legally, you'd have an uphill battle to prove wasn't used by you? Something that would be a prime target of the next worm? I find it's a lot harder to compromise a "klunky" device that's not connected to the computer than to compromise a certificate that is on a computer. Client SSL is snake oil--it's theoretically great, but just can't be implemented securely with current technology.

Re:Time Drift - sliding window

[morzel]

IIRC RSA uses a sliding window to correct for time drift.

In an ideal world, the server and the fob are perfectly synchronized, meaning that the server knows which number the fob will generate at any given time. In the real world, the fob creeps behind/before schedule and generate a number x entries before/after the expected entry.
If this is the case, the server looks up if number x is in the vicinity (e.g.: within 5 minutes) of the expected number. If that's the case, the server assumes that the clock has drifted and marks the amount of time that the fob has drifted for next authentications.
If x is outside that range, but inside a much broader range (e.g.: one hour), it will request the number that the fob generates next, and checks if that number matches the one that should come after x. Then it marks the drift amount and allows access.

The server automatically compensates for inaccurate clocks in the fobs; as long as you use it regularly. Only if you have,'t used your fob for quite some time, and it has a really lousy clock they de-synchronize, requiring a hardware swap (and/or manual intervention from the sysadmin).

Re:whoo.

[bitslinger_42]

Hmm. Did you actually read the fine article you posted? If you had, you would realize that all of the attacks fall into one of a few categories:

1) Targeting users of sdshell and a token card
2) Denial of service
3) Require access to the server network

#1 doesn't apply because this is using the keyfobs, not the token cards. The difference, you ask? Keyfobs generate a 6 digit number every six seconds which is appended to the user's password. Since the password is variable-length (per user), it ends up being much more difficult to guess. The token card has a keypad on it where the user enters ther numeric pin which is mathmatically merged with the 6 digit "random" number, creating a 6 digit code that's sent across the wire. Oh, yeah... The attacker also has to have access somehow to the data stream between the client and the AOL server during authentication, which basically requires pre-compromize of the client machine. You got that, why do you need to fake the auth? Oh, and the AOL plan isn't using sdshell. Other than that, sure it might work.

The second, the DoS attack, is old, and its not like AOL hasn't dealt with DoS attacks before.

The third require pretty significant access to AOL's server network, plus the ability to insert yourself into various server data streams. Again, if you've got that, why waste your time getting a user's PIN?

If you read the hacker rags closely, you'll find that the keyfobs auth is really hard to get around without having to do something else first (i.e. get the server key records). Everything I've read from the attacker's perspective is that, while its technically possible in some circumstances to do an attack on the SecurID process, its usually so damn hard that it'd be easier to attack some other point (i.e. dumpster dive for sensitive info, etc.)