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

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

[nearl]

Can I have a $10 discount and 3 passwords ^^ Average Indian replay

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.

Re:AOL Employees

[davegaramond]

Can't they use a 95% percentile (or 90% or something) to calculate the daily average call time? This way, if you get say 41 calls a day, and only 1-2 calls take a long time, they don't count. But if more than 3 calls take long time, only then they start to affect your average call time.

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.

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

[poulbailey]

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

Such a thing already exists... in Denmark. It's completely free to get a certificate mailed to you and you can use it to authenticate for a multitude of do-it-yourself online services like tax returns and other state/county forms. I think it works quite well.

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?

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,

--

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.

whoo.

[nbvb]

SecureID.

Whoo.

Been there, done that.

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

http://www.tux.org/pub/security/secnet/papers/se cu reid.pdf

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

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.

Sorry this needs to be said, but...

[Anonymous Coward]

like most technologies, this one will never be embraced unless the pr0n industry stands behind it. They've been early adopters on almost everything else that's been successful.

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

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:AOL...cutting edge security.

[BrianRoach]

I worked for AOL for 8 years ... secureID is easy, and keeps the clueless billing reps (now in india I believe) from giving away your account to social engineering "phishers".

The display on the SecureID is just numbers, synced to the auth server. The average user should have no problem entering 8 numbers when prompted.

- Roach
http://www.speedwerks.com

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

Time Drift

[JumboMessiah]

IIRC, The RSA devices that I've used in the past rely on accurate time synchronization with the server. While it was easy for me to have it reset, I wonder how they plan to handle this on a large scale? It would require the end user to physically send the device back to AOL.

I suppose eventually they may integrate GPS timing with them, making it a thing of the past, but who wants your fob tracking you...

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.

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.

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.

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

Social engineering

[maximilln]

How long until the AOL service department implements a policy for allowing users into their accounts when they've lost the SecureID, or their spouse accidentally took it with them, or they're on a business trip and left it at home? I see this being a perfect route for social engineering of unauthorized access.

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?

Re:Well...

[WesG]

Hmmm...Screwed? Nah..I would call this natural selection.

Seriously - its no different than writing your "simple passwords" on a piece of paper somewhere and someone finding the list. For bonus points, what was the password used in Wargames :-)

Kudos to AOL for at least providing this option to the general public.

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?

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.

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:Good deal - basic math?

[Meostro]

How exactly does $9.95 plus $1.95 per month get to be $60/yr?

1.95 * 12 = 23.4

23.4 + 9.95 = 33.35

33.35 != 60

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

The End is Near!!

[Maestro4k]

Oh man, Lucas finally releases the original trilogy on DVD, AOL starts at least trying to have some form of security both in the same day. That has got to be a major sign of the impending apocalypse. If Microsoft announces it's dropping Windows to develop Linux before the day's out I'm heading for the mountains!

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: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:This has been used internally for years

[LetterJ]

A lot of companies use them for their VPN access. Several of the last big companies I've contracted for have required them. Some just use the value from the fob and others require a concatenation of the fob value and a prechosen password.

Unfortunately, I've found that the fobs tend not to enjoy the abuse that being on my keychain tends to bring. The LCD panels end up pretty scratched by the time I'm done with them.

Got a good screen name? Get one of these.

[YetAnotherName]

If you're lucky enough to have a decent screen name on AOL, like your first or last name, then you probably want to get one of these devices.

When I got my Yahoo account years and years ago I was early enough to get decent screen name. The problem is that today that account is routinely hacked (and once, even pwned, but thanks to the nice security folks at Yahoo, given back to me). People don't like to use something like "%geeba%56672" for Yahoo Instant Messenger. I imagine the same thing is true on AOL. Having a smartID or securiCard or other defense would be nice.

(Then again, auctioning off a nice AOL screen name might be worth a few bucks on eBay...)

But you don't need "two" passwords !

[syrinje]

Two factor authentication relies on (d'uh) two inputs to the authentication algorithm - something you know (like your username) and something you have (like a password - whether generated by a SecurId or not).

The advantage of the automagically generated password is that the password is a temporal function of the account. This means that the server and the password generator both work off the same clock base to calculate a password for your account and authentication succeeds if the two match (within some non-zero time window - to compensate for clock drift). the password is thus valid for a very short duration and makes it very hard for a MIM to capture, replay and use

As far as I can see the first (user memorised password) is merely an artefact of an older system left in there to make the user feel good about having some password control since that is the fator that is most vulnerable to compromise (think social engineering).

A more robust mechanism would be to add a challenge response to this mechanism - the suthenticating system gives you two numbers (n1, n2)which you feed into your password generator and it generates the response thus -

R sub t = f(t, n1, n2)

The authenticating system performs the same computation and accepts your password if it matches with the result generated locally. Banks in Sweden have been using this for quite a while now - the password generator is, of course, protected by a PIN number to unlock it for use and therin lies the weakest link!

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:But you don't need "two" passwords !

[Gunzour]

Authentication can generally be done using any combination of these 3 factors:

- Something You Know. Generally a shared secret, such as a password.

- Something You Have. Prove that you are in possession of something. By entering the code from a SecureID card, you prove you are in possession of the card. A physical key entered into a lock is also Something You Have. The CVV code on the back of a credit card is a weak form of Something You Have (it could be argued it is something you know, but online stores are using it to 'prove' you are in possession of the card).

- Something You Are. This is biometric authentication, such as voiceprint, fingerprint, iris scan, DNA check, dental records, etc.

Your username is only a bit data -- well-known data at that. It doesn't count for any of the three factors.

Re:This has been used internally for years

[LnxAddct]

Serious question: What happens when the battery dies? Or more importantly how long does it last? I wouldn't want to have to call some guy every month asking him to reset my password.
Regards,
Steve

Synchronized Clocks?

[ericpi]

One thing I always wondered about these devices, is how you keep the device synchronized with the server. Since the code changes every 60 seconds, the server and the fob have to be set to within 1 minute of each other in order to agree on the same code.

A typical quartz clock has accuracy on the order of +/-10 ppm (parts per million). To accumulate an error of 60 seconds requires only 60 / (10 / 1M) = 6M seconds = 70 days. Therefore, it would seem after a few months, the fob would 'drift' enough to make the codes not match.

Does the user have to manually keep the time set? (Though, looking at the device on RSA's site, I don't see any buttons.) Does the server automatically accept a range of codes to allow for more 'drift'? Both approaches in combination?

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.

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.

SecureID

[Gr8Apes]

SecureID just seems like the next logical step. I used one for 3 years, and, once you get used to not attempting to log into your VPN when only the last bar is showing (there's a countdown bar indicating how much time is left before the number changes) it's really not so bad.

They appear to run on pseudo random number generators, and are synched up with the server with a known seed. I imagine they'd be very difficult to crack, as our system was configured to only allow 1 login attempt per number, if you typed in the wrong password/SecureID number, you had to wait until the next number came along. Annoying, but definitely better than the 3 (or 5) attempts and get a system admin to unlock your account.

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.

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 companyname@aol.com 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:Duh?

[David Rolfe]

I hate to slam you like this, but, you are totally wrong.

As is mentioned in other places in the thread, the token resets every 30 seconds, that's true, but is it so hard to type 6 numbers in 30 seconds? No, it's not. What a ignorant, short-sighted (and possibly mean-spirited) thing to say. I know you are "holier than thou" and none of your friends require physical passwords, because they all have great memories and are full of best security practices; but that does not excuse the need for many people to protect their "online identities".

This is really old news. In CAT and PWA we had been trialling (offering) securID's to customers for um ... gosh I dunno since like last summer? If someone had repeated compromises from phishing/trojans/kids we would offer them a securID.

Parents whose children were on the verge of getting their accounts canceled (and grannies who'd been comped and used as spammers) Loved this feature. So anyhow, this:

Yup that will work for 1% of AOL users. The rest are screwed if it ever becomes mandatory. Sixty seconds is not enough time for about 99% of all AOL users. They'll spend the first 30 seconds trying to get the first password in and then type in the second password in the next thirty seconds -- only to figure out they got the two mixed up. Then they will spend all day typing in the same two passwords until they phone AOL at around 3:30pm.

...is complete BS. SecurID is effective and easy; I did the support to prove it.

(Just don't reveal your tokens. I remember l0pht wrote a brute force for the internal crypt key if you could provide it a number of sequential tokens.)

Sorry that got a little personal. I'm a little riled from the last batch of /.ers slamming AOL's core demographic. Still, needed to be said.

Re:Security Functionality

[Dun Malg]

AOL has local dial-up access pretty much everywhere. Useful for small business and anyone on the road.

Any decent ISP has local access pretty much anywhere. AOL hasn't really had an advantage in that regard for four or five years. The only excuse for using AOL is "not knowing any better".

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)

Sure, it's easy.

[Ayanami Rei]

Get a phone with Java. Make sure your home machine is using NTP (or GPS, or both) to keep accurate time. Your phone should get it's time from the cell tower (or GPS if it has that).

Write a J2ME app (or find one, I think you can) that takes the current time rounded to the nearest minute, asks you for an unlocking-PIN, which is used to decrypt a shared secret. Hash the secret with the current time (SHA-1 is good enough). Show the lower 8-bytes or something.

On the server, write a PAM module that does the same thing, except maybe it creates 8-byte hashes for a minute behind and ahead and behind too, and accepts any of them (to account for time jitter).

So you go to log in, pop open your java app on your cell, type in the PIN, write down the hash, and then use that to login via SSH or FTP or whatever.

Of course, ssh public-key authentication is just as secure as this (you have key halves on each side, the client side's protected by a pass-phrase, you encrypt a random challenge which is dependant on time, among other things...) Actually, I think I trust a PKI-scheme with 1024+ bits more than a symmetric hash-based system.