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

Security Functionality

[Tyndmyr]

Its a security improvement yes...but why would I want to use AOL regardless?

I tried it...it was slow, often down, and required special software. None of which my cable connection is subject to.

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.

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

[MurrayTodd]

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

To my understanding, you would place a client-authenticating certificate in you web browser program, and during the SSL negotiation that certificate would be used for authentication.

The only two problems were (again, to my limited understanding) first that you had to go through the effort of installing the certificate on every browser you used, and second, the security could be broken if someone had access to your account. (Of course, account login security and browser "first-time-on-launch" passwords helped protect against that.)

Why the bloody SecureID system that's so klunky?

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.

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.

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:Not a bad idea

[PugMajere]

When they go out of sync, either they haven't been used in a *long* time, or the server's clock is drifting badly.

The server is designed to track slight drifts in time and track/compensate for the cards.

Even if they are out of sync, the most you have to do is enter two codes instead of just one.

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:Security Functionality

[ptr2004]

For the tin foil hat hearing folk you can get a three password login for one low fee of 5.95

Re:AOL Security at work again...

[Anonymous Coward]

RTFA you nincompoop... one of the passwords changes every minute, and it's generated automatically. So phishing attempts would not be all that successful.

Seen it used..

[the_dubstyler]

My bank uses one of these for online banking, as a protection against keystroke recorders. I suppose I'm just too lazy to actually get hold of one and try it. I figure they're not a bad idea, given that the majority of people trying to hack your accounts are amateurs who would be put off by it.

Hmm

[Bigthecat]

As I'm sure many people here have noticed these before, they've probably also noticed how often they go missing. For instance, the employees of a large company right here in Australia are all given these, along with their laptops and logins.

These people aren't techheads, and most of them write their passwords down on pieces of paper, conveniently attached to their laptops, which is then conveniently placed in their work briefcase, along with the password updater.

Sufficed to say, dozens of these briefcases get stolen, in the same bar frequented by employees of this company every six months (One might ask why they still take their gear there). The thief gets an expensive company fleet laptop, a company password list, and a company satellite password updater, all packed in the same convenient suitcase with a carryhandle ready to go missing.

Ultimately, no matter how many security measures you put in place for a company or organisation, you're going to encounter people who write down their passwords, people who fall for emails from tech support who need to 'verify' their accounts and ultimately people who will have their information stolen and not report it for days, which is plenty of time for the thief, and a less-than-ideal amount of time for people like you and me to have enabled compromised accounts running on the system.

Serious business people use AOL?

[siliconjunkie]

This is a great feature to have from an ISP, and the technology is sound (we used similar "Crypto Keyfobs" when I worked at PacBell for logging into the system remotely when in the field)...but I must admit I am surprised that it's AOL offering this kind of a thing.

I used AOL years ago, and have used it from time to time recently on other people's computers, and there is nothing in the "AOL package" that I have seen that says "power user" to me.

So I guess what I am wondering is...is this something that AOL users are actually clamoring for....or has AOL finally sucked up all the "n00b" market that there is and is trying to offer services that would appeal to more of the "slashdot crowd"?

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.

Well...

[ImaLamer]

What happens if I lose my SecurID?

Seriously. If I set my password to "password" and someone picks this up then I'm screwed, right?

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:Useless

[Lord Ender]

"When common folk's computer is still infested with adware/trojan/god-knows-what

This just creates an illusion of security."

Wrong. You could have a damn key logger on their computer, it doesn't matter. The SecurID password expires every minute.

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

[Fedallah]

After reading through the paper, I have to say that the attacks contained therein are simply not that impressive. In it, the author describes the following attacks:

• An race attack that is only valid if the user slowly logs in over an unencrypted non-line-buffered telnet session using the SecureID. I have never seen an implementation of SecureID used like this, and we can be assured AOL's implementation will not be susceptible (as they will undoubtedly be having the token typed into a local window, not transfered over a network character-by-character)
• A attacked on a clustered implementation where the attacker shuts down several lines of communication as part of the attack. This is probably the closest thing to a dangerous attack; however, the author even describes a way that the servers could be programmed as to avoid this situation. At the time of the article, this has not been implemented in the server, but apparently, the article was written in 1997 (or thereabouts)
• A software bug in an older version of the software. Shameful, yes, but apparently fixed about 8 years ago.
• A theoretical attack of which the author claims "It is not known whether all of the semantics are
  absolutely correct in this example but it is quite probable that some variation of the
  attack is possible."

Of course, I'm not claiming that the security of a SecureID implementation is unassailable, or that SecureID is a panacea for security problems. I just don't believe an old article that describes some irrelevant not-quite-attacks is sufficient to cast doubt on the extra security provided by SecureID, and that attacks on SecureID are actually much more difficult than you seem to be claiming.

Re:This has been used internally for years

[LetterJ]

I haven't had a battery go dead in one yet. Granted, I haven't had the same one for longer than a year, but physically, the display is pretty much what a digital watch would be. There's no backlight, etc., just a string of numbers and a little countdown meter. Internally, it's doing more calculations than a watch does, but we're still talking about a really small electrical draw.

Incidentally, there's an expiration date on the back of these things (I just thought to check). My current fob has an expiration date in Dec of 2007. I think that's a pretty good duration and it's more likely the thing will get destroyed by being dropped on the pavement, lost, scratched beyond usability, etc. in over 3 years of use on a keychain.

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.

Re:Synchronized Clocks?

[PalmerEldritch42]

The server does allow a range of codes to work. I have been using SecurID and you can put in the tokencode from 1-2 minutes ago and it will let you in. So, if the token gets out of sync from the server, it is ok. If it gets too out of sync, then you need to call the help desk and they can resync it using some online tools. It takes less than a minute to do. I've never experienced a time drift problem that resyncing didn't fix, but theoretically, if it cant sync back up, they can always just send you a new card and use that one instead.

Re:anti spyware / trojan

[MBaldelli]

why dont they plop a big donation to spybot and include it ?? Or fine come up with their own.

You mean assimilate, like they did Netscape and ICQ? Thanks, I would prefer Spybot be free of the AO-Borg assimilation.