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 ;)

AOL Employees

[Anonymous Coward]

Used to have to use them, smartID or something. ALL internal accounts were locked... its a very secure system, but hard to believe that users would actually want to use it.

Re:AOL Employees

[macthulhu]

I still work for The Deathstar.... oooops, I mean AOL/TW (Go easy on me, I work on the less evil side... Time Warner Cable). We use these RSA IDs. They're not so bad. The part of the login that asks for the number actually goes faster than the normal login procedure. I know you need it to access that account from any computer via AOL or their Webmail interface...

As for using it for other systems (VPN, etc.) I would be really surprised if they would let you do that, even for an extra fee. Tinfoil helmets and extreme security paranoia are rampant in our IT people, mostly AOL guys. Our network is built on the 'Security Through Confusion' model. Their answer to getting me intranet access from my video production machine was to ship me a low end Dell that they would allow on the network. It still doesn't address the issue of my need to take :30 TV ads from the production machine, and send them to people on the network.

So, no, I wouldn't expect that they would help you use the RSA fob for anything other than getting your spam, er.... email.

Re:AOL Employees

[clickster]

Depends. I worked as a call center tech from 1997-1999. I'll outline the problems that I had. First, you are nothing more than a number (or numbers). You are employee 28645. You must maintain an average call time of no more than 7 min 30 sec, an idle time of 3% or less, and lose no more than 15 minutes off of the phones in an 8 hour shift. That is all they care about. Oh, and maintain good customer service stats at the same time. It's like the real-life interpretation of a Dilbert comic. You have to fix the customers problems and make them happy. But don't take more than a daily average of X number of minutes. This sucks when someone who has had AOL for years calls with a problem that takes hours to fix. You can A. Spend time fixing it and screw yourself on call time or B. Dump the call to save your call time and hope that they aren't one of the few callers who get a "how did we do?" e-mail that will lower your customer service scores. I quit because I got sick of conflicting signals I kept getting from management. "We're all about servicing the customers". But that was only if you could do it in the correct amount of time. They wanted satisfied customers, but didn't want to spend any time with them. Oh, and they put the responsibility for resolvong that paradox on your shoulders. If you fail, you're fired. I had one of the highest customer satisfaction scores in my call center. Because I fixed peoples' problems on the first call, rather than giving BS and dumping calls and forcing them to wait on hold 3 times to get a solution (something like 90% and 95% when the call center averages were around 60% and 65%). But that killed me on call times. If a customer called in with problem A and I knew that down the road they were also going to run into problem B, I would fix both problems, while most people who valued their jobs would fix problem A and let them call in again in a week when they ran into problem B. This could all be solved if management could pull their heads out of their butts and realize that one 10 minute call that fixes a problem costs less than three 5 minute calls. And the customer leaves happier. Save your sanity. Tear up the application.

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,

--

This will make the problem disappear.

[AhabTheArab]

Great, now phishers will have to ask AOL users for their password twice, and they will gladly comply.

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

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

[dr_dank]

Why the bloody SecureID system that's so klunky?

Klunky? Given the average skill of the AOL user, telling them to punch in the code from the SecureID keyfob couldn't be easier to do. Better than importing and keeping track of ssl certs across machines.

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

[k98sven]

All it does is make an attack "more" difficult, but nowhere near impossible

Yes. Exactly like every other security system ever designed.

Your point is?

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

Aol must really care about security...

[SirTwitchALot]

because they can't be making much money from this:

RSA sells these devices for $60 each or so in bulk. RSA fobs are programed to expire in 36 months. Let's say AOL got them for $50. The customers are paying 9.95+(1.95*36) or $80.15 over three years. That gives AOL $30.15 or about $10 a year. I'm sure aol could find some other way to fleece their users less than a dollar a month, leading me to believe this isn't just some profit making venture (not to mention the cost of the servers to implement this, which is not insignifigant.)

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

Re:Security Functionality

[gcaseye6677]

What I'm curious to see is how this would affect "people who conduct large transactions online", who the article said were one of the target groups for this device. There are currently no plans to integrate this with banks or credit card companies, so how exactly does this protect peoples' account information? If bobbyjoe44@aol.com has an account at Bank One, I can still send them a fake "update your information" email, they put in their Bank One password and other info, and I get into their account. Meanwhile, the keygen thing is only protecting their AOL account and I'm cleaning out their bank account.

The only thing this really secures is AOL's bottom line, by preying off of peoples' fears and giving them something that makes them FEEL more secure online.