OK, to address a few criticisms of the proposals: > I have huge problems using cookies for authentication purposes of any > kind. Why couldn't I capture your cookie and be you? If I got into your > machine, what would stop me from using your cookies?
Then don't use them. Cookies are entirely optional if you look carefully - all they are used for is speeding up the login process by allowing sites to remember your network address, and for the authentication site, the credentials (which would be encrypted so only the authentication site could read them btw). If you don't wish to have your credentials stored, then simply uncheck the "Remember Me" options on the relevant sites: tada, no cookies. You have to re-enter your credentials each time which is a bit of a pain, but you do get the increased security. But if say users were to use cookies in ignorance let's take the second case first, as it is more likely. If for instance I sat down at somebodies computer while they were signed in, what would I realistically be able to achieve? If we assume that the user has visited a negligent site that has not encrypted its cookies, I would be able to determine the persons username by reading the cookie list in Mozilla/IE or whatever. I would not be able to determine the users password, because it's encrypted. I could copy the cookie from one computer to another manually, in which case the machine would have been "ghosted". Here's one way the amount of damage this could do could be limited: The first time you visit the sign-in page, a counter is initialised to some random number (maybe taken from the time), and hashed with the credentials and stored. The counter is saved in the users account. Next time you visit the sign in page (which will happen even if all your credentials are stored: bear in mind that visiting xyz.com will always redirect you to the sign in page once you've signed in once with xyz.com) , the credentials are read from the cookie and checked against the counter. If they match, the counter is incremented, and the credentials are rehashed, and the cookie reset. Now let's assume that somebody steals a sign-in cookie. As soon as that cookie is used to sign in to a site, it's invalidated. So if the real user attempts to sign in again, they'll receive a message saying that the cookies have become desynchronized or whatever, and the user is automatically logged out. The only way forward is to represent your credentials over an SSL link, and sign in all over again. Of course, if the real user is the first to visit another page that supports SSI, then the stolen cookie is invalidated and the thief gets nowhere. This is not a perfect system of course, and if the thief is first then they can sign in using somebody elses cookie. But these weaknesses could apply to any sign in system on the net today. In fact, we've already got an imperfect SSI implementation in place today: on most sites, if you forget your password you can have it emailed to you. So really the only password that truly matters is your email password, which is often transmitted in the clear anyway. Where are all the evil hackers stealing email passwords and using that to sign in to Amazon under other peoples names? > > _Arbitrary services_ > > We will use the example of a jabber aware FTP server and client for this > section. > > 1. User connects to jabber-aware FTP server using jabber aware client > 2. User gives client username and credentials (password, certificate, > whatever) > I capture the credentials. Using what, a keyboard sniffer? Fine - any security system is vunerable to this sort of attack. I don't see your point. > I was going to type in RFC1510 here. Here is a link > http://www.ietf.org/rfc/rfc1510.txt . > The big concept I want to drive home here is that no passwords or other > relevant pieces of information that could be stolen to impersonate > someone are sent over the wire. We really should consider that when > creating an authentication protocol. Tell me why I am wrong. Not having credentials sent over the wire significantly increases complexity and reduces usability. If we did this, we'd end up with Kerberos. Show me where the millions of people using Kerberos are. They aren't there, and they aren't there for good reasons: it doesn't work on the web. It also requires clients to be especially written, special servers to be set up, and is not properly supported on Windows (it doesn't exist in Win9x, it exists in a broken and MS specific form on Windows 2000). OK, this has turned into a rant, for which I apologise, but a rant it will be. I see this all the time: developers sacrificing usability for security, in the mistaken belief that black hats will tear people to pieces unless it's 100% impenetrable. Not true. At the end of the day, SSI is about convenience. I'd like to use one password to sign in to all my websites and yes in the future FTP servers and other things too. I'd like to type in my username and password once, and then for the network to remember all this and not prompt me again. This opens the system up to abuse of course, even if it's just my little brother sitting down at the keyboard while I'm out of the room and looking at my eGroups preferences. But I'm willing to accept less security for more convenience, and many other people are too. It's a compromise at the end of the day between the ultra-tight security of Kerberos and a real world implementation that's easy to use and develop for. I stick by it. thanks -mike _______________________ Michael Hearn [EMAIL PROTECTED] Jabber (jabber.org) [EMAIL PROTECTED] ICQ# 34800568 _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
