someone at my firm is about to press the securid system down our collective throats. please point me to the recent thread on this subject, and/or point me to some url's or the like, or to someone who has some firsthand knowledge of the pitfalls and/or vulnerbilities of secirid. cheers, -paul
I've been using SecureID for the better part of a year now and am quite pleased with the way it works. Here are the negatives, though they are not very interesting: -- There is a false rejection rate of around 2-5% (failure to login with my presumably valid SecureID card). This includes modem bobbles and database crashes. It generally is self-correcting. -- Dialup access only. This would prevent me to access my mail server (which is inside the firewall) from telnet. -- Interactive access only; I can't program my home machine to dial in at 5:00 AM to read mail without intervention. -- We have a mixture of direct and 800 number dialups -- this presumably protects against problems unique to a single server. In my case, SecureID is integrated into ARA (Apple Remote Access). Client installation was trivial. I don't know what, if any, link-encryption is incorporated. The user overhead is about 30 seconds per dialup. Martin Minow minow@apple.com
someone at my firm is about to press the securid system down our collective throats. please point me to the recent thread on this subject, and/or point me to some url's or the like, or to someone who has some firsthand knowledge of the pitfalls and/or vulnerbilities of secirid.
cheers, -paul
Paul J. Bell wrote: | someone at my firm is about to press the securid system down our collective | throats. please point me to the recent thread on this subject, and/or point | me to some url's or the like, or to someone who has some firsthand knowledge | of the pitfalls and/or vulnerbilities of secirid. www.l0pht.com/~mudge/skey_white_paper.html has many attacks which will work on securid as well as s/key. The software is slow. The Ace/Server calculates expected values of information by running stuff through des & f2. This is slow. It also encrypts the logs, which can be slow. I've found that a sparc 2 can die under the load of 2 people running sdlogmon, one running sdadmin, and 2 or 3 people trying to authenticate. (This seems to be bad design, since the Sparc2 has hardware des in it, which they don't take advantage of. The software is not the most bug free. I'll flame at length about the fact that you can't get source to fix the bugs yourselves. I looked into hacking in a new des library (shared libraries are great sometimes) to fix the slowness problem, but without source it turned out to be more effort than buying a faster machine. You're stuck with their hardware. With some other systems, that use open standards, and you might be able to switch card vendors. With SD, you must buy new cards from them every three years. (SD claims that their cards have a much higher failure rate after three years, and that this is a feature.) You're stuck with their software. SD libraries must be on every machine that they authenticate for. You can't bugfix those libraries, even if you replace things like sdshell (an analouge of skeysh). (sdshell, incidentally, munges wtmp on solaris machines because it doesn't use the right library calls.) This also means that you can't run on unusual machines, like a BeBox. There are of course more fundamental things, like the fixed length authentication code, the lack of peer review on the hash algorithims, and the lack of ongoing authentication. Also, I have a few cryptographic attacks on the system which I hope to present at Crypto's rump session, and I'll put on the web afterwards. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
participants (3)
-
Adam Shostack -
Martin Minow -
pjb＠ny.ubs.com