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

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.

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.

noone will get this

[Anonymous Coward]

because it costs money.

"Identity theft only happens to other people"

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,

--

AOL...cutting edge security.

[Captain BooBoo]

This is going to be a complete waste of time IMHO. The AOL user base is such that a typical AOL user has a password like " password" or MikeJohnson". How do they expect users to be able to handle a second password that is strong? " I forgot my password, can you help?" Yes, just read the display on your password generator." "ok what does "dgR23Ls12S" have to do with me? My name is Mike Johnson"

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.

Big Deal :)

[purduephotog]

Had this ability for corporate accounts for some times. And the problems have never been addressed, some of which:

1) Long dial in times result in the 2nd password changing before completion, thus requiring a 2nd attempt (or a 9th, depending on how pathetic the phone service is)
2) Annoying easily lost dongle on your keychain that says "RSA- STEAL ME" in big bold letters. ...

So yeah, I'm thinking it's a great step. But not for AOL.

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.

Businesses us AOL??

[bcarl314]

It's aimed at small business and people who conduct large transactions online

Just a comment (read opinion), but unless you have no other options, why would you, as a small business owner, use AOL to "conduct large transactions" online.

Mod me troll if you like, but I don't consider AOL to be a very "business friendly" organization.

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

heh

[H8X55]

And yet AOL still reccommends to its home users that they store their passwords in a less than secure format on their local PCs.

Re:Big Deal :)

[gfxguy]

1. The way it gets used is not for establishing an internet connection, but authenticating the user (broadband users, for example, still need to use one). So you establish your connection, then a password prompt pops up then you type in your password. No automation = more secure.

2. You have an established password PLUS the securID password... even if someone you know steals it from you, and they know your login and have your securID, they cannot log into your account unless they ALSO know your private password, which can't be easy like "mike" or "john", because it's all numbers. Now, sometimes people use stupid numbers (birthdays and so forth), but you are still talking about having two "keys" in order to log into an account.

Re:whoo.

[lysander]

For the external attack described in the document you mentioned, it assumes that the SecureID token's value is sent in the clear. I don't know about you, but this seems like a pretty big assumption. If one enters the value over SSL or SSH, observing the value over the network is harder, and makes the first attack not feasible.

That leaves the rest of the document describing attacks between the machines that verify the value, which hopefully are internal and not snoopable from the outside.

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

Not quite...

[Millennium]

Two-factor is indeed based on something you have and something you know. But "something you know" isn't your username; that's "something you are". "Something you know" is, in fact, your password.

Two-factor authentication actually has three factors. The username part is so insecure, however, that no one really counts it, because everyone has to know it in order to do any business with you at all. Many graphical login managers even present a list of usernames, because keeping these secret hampers the system's usability -no one knows who anyone is- for no real security gain.

The user-memorized password is not "an artifact of an older system"; it is still an important part of security, It is no longer the only important part of the security process, but it retains its importance.

Re:But you don't need "two" passwords !

[Kiryat Malachi]

Without the user-memorized factor, the token (secureID or otherwise) becomes the entirety of the password, making it no better than a key for a lock - if it goes missing, your security is nil.

Essentially, the two-factor system needs both the user-generated factor and the automatic factor - the automatic protects against social engineering of the user, and the user protects against physical engineering (i.e. theft) of the automatic.

Re:Aol must really care about security...

[slungsolow]

I am sure that the financial hit isn't as bad as you made it out to be.

1) They wouldn't have purchased a small amount of fobs. We are probably talking about an order between 100,000 and 1,000,000. That means they probably received a vast discount. The fobs themselves are glorified calculators that run off of a preset algorithm. They most certainly wouldn't cost upwards of $50 a piece. I am sure that they are partnering with RSA for this business venture.
2) The security features were already put in place so all they had to do was beef it up a bit, so again, the initial investment isn't that great.

3) They are a corporation. They wouldn't do anything if it didn't have the promise of a return on their investment. They wouldn't do something like this unless they researched it and found that there was a need and that they will be able to make a...
4) PROFIT!!!

I of course just don't get it. Why would people want to secure their data on the client end when they should be worrying just as much about the data stored on the server end. What is AOL doing to ensure that the data is kept secure throughout the whole transaction? Is this whole secureID thing just a method of coddling their non-technical customers (Look you get fancy number changers for your keychain!!!).

They even branded the secureID with AOL graphics and colors. Its insane.

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 [e-mail] 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.

Small Business, Large Transactions and AOL?

[graphicartist82]

"It's aimed at small business and people who conduct large transactions online."

These people use AOL? I sure wouldn't do business with any company whose e-mail address was [e-mail] or whose web page was http://hometown.aol.com/coolguy12345

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.

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

[virtual_mps]

For starters, while it is possible to use client certificates without any further security, in practice the minimum security on the private key for a client certificate is a password, which because it never leaves you machine is much less susceptable to interception than a password sent over the internet.

But does nothing against a client-side compromise. Look at the stats on the number of home PC's with cable modems that are being bought and sold as zombies. In practical terms, the odds of having your password stolen via a local compromise are probably higher than having your password stolen on the internet over an ssl connection.

There are also hardware devices that can either hold your client certificate, or do the authentication needed to use it, which protect you against locally installed keyloggers.

Yes, and these have their own problems. First, you need a hardware device and an interface to the system--which makes them no less "klunky" than the securid's the OP was complaining about. Second, the interface is a hard problem to solve for the home user. Do you force the user to do something at the hardware device for each use of a client certificate? (Good luck getting that adopted, and good luck teaching the user to distiguish "good" requests from "bad" requests.) Or do you authenticate once per session, which once again leaves you open to attacks if you have a compromised workstation?

Re:Security Functionality

[slycer]

They do go occasionally, and sometimes the cards get fucked - they're not super delicate, but enough abuse and they'll stop working.

The RSA admin tool allows an administrator (or someone with elevated privileges) to set a card into "lost mode", which allows setting a static password, and an expiry date for the lost mode - after which it disables the static password.

So, sending a card out via mail, should reach the user by the time their static password is going to expire, and they're back in business using the card.

I've worked with these things for somewhere around 7 years, and I pity the support people for AOL, and pity those that will need to use these cards. When they work, they work great, but it seems a fairly common thing for the cards to get out of sync with the server, in which case someone needs to resyncronize the card. It's a common enough problem in a smallish (~5000 users) support base (used for VPN, so you could knock that down to a percentage of that 5000) that I can easily see the support costs for AOL going wayyy up. And that's just a minor problem with the system.... there's also the case of a server crapping out (which can be semi-solved with redundant servers - which adds it's own problems to the mix)

Not $60 ... recheck the financials on this.

[Anonymous Coward]

The fobs are only about $20. I used to work at AOL, and if we lost ours, that was the charge to the department for replacement. $20. That's the rate they buy them at for 9000-10000 employees. They do a deal with RSA to open up SecurID to the world, the price will go down significantly.

I'd be willing to bet that $9.95 is break-even cost on the fob, and the $1.95 gets split evenly between RSA and AOL.

So far, analysts predict this to only appeal to a narrow range of AOLers, guesstimating 5 to 15% of the member population. On the low side, let's take 5% of 30MM users, = 1.5MM people. At a measley $0.975 each (revenue split with RSA), * 1.5MM users, that's $1.4MM per month, that's about $17MM/year of revenue for AOL and $17MM/year for RSA.

I'd like to be the guy who found $17MM of revenue for my company.

Plus, as it's already there to support employees, the infrastructure is already built in to the AOL login servers, so there is no net new cost there.

Last I knew, only OpsSec had access to bind/unbind fobs, sometimes you also needed to resync them. But, it would be trivial to train the member services team on resetting the fobs, resetting, etc.

From a security perspective, now instead of simply calling up and pretending to be you to get your password reset, I call up pretending to be you, and have lost "my" fob and get the account unbound until I find it... but maybe they'll have some precautions around that.