Mutual Authentication Possible?

[James Ellis]

In a browser/server web application (such as a J2EE application), is mutual authentication possible WITHOUT the use of client certificates? I can't see how it would be...

[Ulf Dittmer]

I'm sure there are ways to hook up biometric hardware, but that's probably not what you have in mind ... ?

What scenario are you trying to tackle? A username/password combination is a form of authentication, too.

[Aryan Khan]

As Ulf rightly said, what do you want if not certificates.
I would say anything else will require effort as certificates will be handled by the Web server and the browser transparently.

Aryan

[Nicholas Jordan]

I have given this a great deal of thought. I also have several books by people who know what they are talking about. Unless you use some kind of professionally written tool such as certs or other java.security mechanisim, then its totally TeleTubbies meets joyous JellyBabies - all the way down Primrose Pike.

That is until someone takes your business away from you.

[James Ellis]

What scenario are you trying to tackle? A username/password combination is a form of authentication, too.

True...but it's not "mutual" authentication. In the typical username/password certificate on the server scenario, the browser can authenticate that it is really the public key of the server that it has obtained because it is signed by a CA. The server however, can't authenticate that the user is really who they say they are (outside of the username/password). If the client had a certificate that the server trusts (as well as username/password) then both are "mutually authenticated".

The problem I see is that distributing client certificates to all of your users (even in a B to B application with only a few hundred users) could be a nightmare.

That's why I am looking for a mutual authentication scenario that doesn't involve client certificates...but I don't know how it would be possible without "something" (like a certificate) that the client already has...
[ February 29, 2008: Message edited by: James Ellis ]

[James Ellis]

then its totally TeleTubbies meets joyous JellyBabies - all the way down Primrose Pike.

...come again?

[Nicholas Jordan]

I just get nowhere, all too often, and it seems to derive from a sort of "it doesn't really matter' mentality I find pervasive. I heard that term recently and it fits what I have to battle in my mind - the translation is discussed thoroughly in security literature.

E.G. Military Grade Encryption and so on, the term TeleTubbies meets joyous JellyBabies would transliterate as Base64 encoding for encipherment and peppermint lolly-pops sold to children too young to deal with the pepper-mint.

For example, I'm trying to re-write a large source file. I get ClassSpider from an inadvertent keystroke. That contrasts with the usual explainations of security. Where's the security ? In the Jelly something or other, I am open to new nomenclature but we may need to work it in Meaningless Drivel.
[ February 29, 2008: Message edited by: Nicholas Jordan ]

[greg stark]

...True...but it's not "mutual" authentication ...

Sure it is. The client authenticates the server using PKI and the server authenticates the user with a username/password combo. Aside from the typical weaknesses of human generated passwords, what is there about this authentication sequence that is not mutual.
[ February 29, 2008: Message edited by: greg stark ]

[Nicholas Jordan]

Originally posted by James Ellis:
(...snip...)The problem I see is that distributing client certificates to all of your users (even in a B to B application with only a few hundred users) could be a nightmare.(...snip...)

That is very correct, so you have to think about who it is you are dealing with - both on your own campus as well as at the server farm ~ be that as it may. There are some studies in group behaviour that are not a welcome sight, strong ( or just decent ) proof through PKCI or something ( whatever you come up with ) has to rely on the concept of trust.

Trust is a new concept, introduced by Modern Cryptography. Classical Crypto hinges on everybody is at The Fair, where if you look at it nothing is fair. I think that is what took down the Roman Empire. Earlier than that there was such a thing as Neanderthals, using take care of your own self.

They were wiped out by the later two camps.

[James Ellis]

Sure it is. The client authenticates the server using PKI and the server authenticates the user with a username/password combo. Aside from the typical weaknesses of human generated passwords, what is there about this authentication sequence that is not mutual.

I think it is that weakness of the username/password combination that leads security professionals to not consider this scenario as true "mutual authentication". For instance I could steal or guess your password and then from my computer log in as you and do whatever I want. If the application required the user to have a client certificate I'd have to steal/guess your username password AND steal a copy of your digital certificate.

I won't pretend to be a security expert, but I know that the username/password combination combined with a server certificate alone isn't classified as "mutual authentication".
[ March 02, 2008: Message edited by: James Ellis ]

[Ulf Dittmer]

Originally posted by James Ellis:
[QB]For instance I could steal or guess your password and then from my computer log in as you and do whatever I want. If the application required the user to have a client certificate I'd have to steal/guess your username password AND steal a copy of your digital certificate.

Or just sit at my computer, where the certificate is installed in the browser :-)

But I see your point. "Real" security would at least involve a two-factor system, where the password could be one factor, and the certificate the other IF it wasn't installed but instead read off a device that you carry around.

[Nicholas Jordan]

Originally posted by James Ellis:
I think it is that weakness of the username/password combination that leads security professionals to not consider this scenario as true "mutual authentication". For instance I could steal or guess your password and then from my computer log in as you and do whatever I want. If the application required the user to have a client certificate I'd have to steal/guess your username password AND steal a copy of your digital certificate.

You're getting warmer. It takes about five cycles to get around some grasp of the breadth of the arena. If you aquire good credentials, be they from Public Key Infrastructure or Skipjack or saliva samples, there is still the human mind running on a machine that has it's historical origins in fantasy and role-playing. An accomplished master could break your best efforts without a cross-control network of traffic-logs, open-disclosure, pkci + pw/username, and just plain common sense backed up by reasonable backups and record locking in combination with no back-chaining of deletions.

All deletions are in the form of a record that is what is to be deleted. You save both the deleted item and the instruction to delete it. Without a network timebase, Rubber Ripper can reset the clock back while making the update, sacking someone else for the fall and escaping detection without the control-net 80+% functional.

Cross-checks are Accounting 101.

I won't pretend to be a security expert, but I know that the username/password combination combined with a server certificate alone isn't classified as "mutual authentication".

Why not ? There are plenty of them, they run the Military Grade Encryption industry. It is profitable, selling Snake Oil by the barrel. The server/client pair can authenticate using pkci - this is a proven machine to machine tool. Username/passwords are subject to risks you have not thought of yet: taping to the monitor + Gone With The Wind + losing the thumb-drive + drive-failure + placing them cleartext on drives + enciphered password stored on drive.

Study one-way hashes, let me know if you think of anything.
[ March 02, 2008: Message edited by: Nicholas Jordan ]

[Aryan Khan]

I am not sure if you can consider RSA SecureID. You will still be using passwords but higher level of trust (2-factor authentication).

Aryan