Flutterby™! : Trusting Auth 2008-12-17 01:55:42.665658+00

Trusting Auth

2008-12-17 01:55:42.665658+00 by meuon 6 comments

Today I became a Certificate Authority thanks to TinyCA, and I'm re-writing all kinds of user authentication code. "Simple Auth" transmits login and password in plain text, but I've recently only used it for less important things and via https. I'm now using "Digest Auth" which hides the password data in an MD5 hash with other things, and you replicate the hash on the server side. It seems to be the best authentication mechanism out there.. and yet my partner asks "the question" why don't the big financial sites and google use "auth" methods? Instead they use a combination of sessions/cookies that I call "Fake Auth".

I'll contend there are two reasons: The web monkeys didn't know how to do real auth methods, and marketing biz-dev types didn't like the auth mechanism popups or the harder "logout" multi-step processes. The "Fake Auth" methods simply delete/munge a cookie to logout. The "Fake Auth" methods also seem prone to session hijacking and man-in-the-middle attacks.

And now, for a very specific set of users using touch screen kiosks.. I am having to implement "Fake Auth" so that they can login and do things with a browser based JavaScript keyboard. I'm not happy about it even while we have some interesting things like https via our private certs, and login velocity monitoring, and IP white/blacklists.. and.. and.. I still find myself just not trusting any authentication method much. or browsers.. or.. well, as I fall down the rabbit hole or paranoia, much of anything. Mostly myself.

I've reached the level of security Zen awareness where I wonder if I can even comprehend how much I don't know.

Doesn't digest auth require the server to have a plaintext copy of all of the users' passwords, in order to check the hash? I'd consider that a pretty big security issue...

One of the benefits of digest auth is that it makes phishing more difficult -- you only get a hash back from the user, which is pretty good protection from a man in the middle attack.

On the wire, though, digest and 'fake' auth look much the same -- an opaque gob of data in the HTTP header. An eavesdropper can steal either of them to gain control of a session.

Dexev, I've fought having passwords stored in plain text for years. In this case it's reversible pseudo-encrypted for less than 50 users. I have not yet figured out a way to store a true encrypted password and use it for the digest auth, which is an issue with such methods.

I'm relying a lot on https and hand installed client certs to keep the eavesdropping down, and I'm hoping that most of this traffic will be on a private network. Public IP connections are limited to one useful, but not powerful level of connection.

Shadow -- I could see doing a DH key exchange with javascript on the client, but at that point it's easier to just use SSL (which will do key exchange in the background).

The big threat we were concerned with at my last job was phishing -- specifically, people putting up look-alike pages (or better, just proxying our site) to capture user credentials. It's a surprisingly hard problem. People only notice that the site *looks* the same as the one they want to sign in to, but don't do things like check the location bar.

Meuon, can you use your client certificates for authentication too? Keeping digest auth, that would get you pretty good two-factor auth.

#Comment Re: made: 2008-12-17 21:21:41.8166+00 by: meuon [edit history]

Yep. we haven't made it work yet, but we'll be generating client certs. That's why we became a TinyCA. The DH key exchange is cute, but somehow I just don't trust Javascript in the browser for such things.

I'm back to Simple Auth for a while, while I sniff out the differences in various MSIE/FireFox issues with Digest Auth on MSIE and Safari. Got 2+ months to deliver this thing.. I'll get it the way I feel comfortable, soon. In reality, I only need to make it work for FireFox, but I'd like to be able to recycle this code into other places that use MSIE and other browsers.