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."
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?
Murray Todd Williams
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...
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.
Other than that, Mrs Lincoln, how did you enjoy the play?
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.
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.
+++ATHZ 99:5:80
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
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
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?
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.
The cesspool just got a check and balance.
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.
Someday a real rain is gonna come...
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.
If you mod me down, I shall become less powerful than you could possibly imagine.
Great, so now we can be pretty sure that the person who logged into your AOL account is you. And for AOL services, they have a better trust of your identity. Well and good.
But the average user has more places they log into than just AOL. They log into the bank website. The phone company to pay the bill. The credit card company. etc...
I see 2 options here before this is more than a "so, what?".
1.) You get a seperate RSA keyfob for every site you log into. Which is obviously silly.
2.) Your AOL account becomes a "master account," where the credit card company, the bank, etc., all assume "well, if AOL thinks this is Bob, it must be Bob!" And that's Microsoft work!!! But regardless of who it is, it would imply placing your absolute trust in AOL (or someone else) as guardian of your identity, for EVERYWHERE you go online. Also implies that everyone agrees that AOL is authoritative. Merits of this have been debated to death, my opinion is "good idea in theory, but I trust AOL to have bug-free, unbreakable code about as much as I'd trust Microsoft....
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
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:...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
Read Heinlein's 1953 Revolt in 2100, now more than ever.
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".
If a job's not worth doing, it's not worth doing right.
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.