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

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.

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

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

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