Hacker News new | ask | show | jobs
by marshray 5409 days ago
We've been doing this on the desktop for years.

It didn't hold up well against attack there but there was usually an underlying bit of assumed trustworthiness on the local network that shifted the blame.

But protocols designed for enterprise desktops always turn out to be an unmitigated disaster when run across a hostile internet, particularly from a security perspective.
1 comments
charlieok 5409 days ago
Kerberos fits your description ("protocols designed for enterprise desktops") exactly. The hardest thing I've found about running it across a hostile internet is dealing with NAT issues. The (latest version of the) protocol itself is pretty decent from a security perspective.

Then again, the original version of it, when it was designed for enterprise desktops, would not be particularly effective.

link
marshray 5409 days ago
Actually, Kerberos was designed at MIT for the explicit scenario of an untrusted network: "I'm OK, you're OK, the network is hostile".

It may work acceptably for VPN-like applications, but how does it work for actual internet applications? E.g., how do you enroll new clients into the authentication realm over the internet?

link
charlieok 5408 days ago
Yes, it was designed for an untrusted network. But, there are good reasons why older versions of the protocol are not trustworthy today, which go beyond the increase in computer power relative to the key space [1].

The problem with enrollment is more or less the same as the problem with enrollment using any other crypto trust scheme. In the most secure situation, you'll want to start the process in person.

In practice, with kerberos you have to trust the KDCs holding your keys. With asymmetric systems, you have to trust the CAs who have signed the keys of the parties you are communicating with.

I agree that it isn't a good solution for what we might call "web scale" applications. It is a reasonable way to do password authentication, but federated authentication would require establishing cross-realm trust between identity providers and relying parties.

[1] http://web.mit.edu/kerberos/krb4-end-of-life.html

link