Re: Maybe It's Snake Oil All the Way Down
James A. Donald writes:
Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password.
They could not do this using the standard IE webbrowser. They would have to get users to download a custom client, or at least, like hushmail, a custom control inside IE.
Why do you say that? You were already given pointers to how they could configure their web servers to use certificate based client authentication. These techniques work with standard browsers. I have used Netscape to access corporate-internal sites which required me to have a client certificate.
HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time.
HTTPS is just HTTP over SSL/TLS. It says nothing about the trust model for the certificates; it merely specifies how each side can deliver its cert(s) to the other side. Deciding which ones to trust is out of scope for TLS or HTTPS. E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so? Well, it's a lot of work, and it would have some disadvantages - for one thing, customers would have difficulty accessing their accounts from multiple sites, like at home and at work. Further, it would require customers to use some features of their browser that most of them have never seen, which is going to be difficult and error-prone for most users.
Anonymous Sender wrote:
James A. Donald writes: E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so? Well, it's a lot of work, Nope. issuing certs to someone is trivial from both a server and a user endpoint - the user just gets a "click here to request your key" and hits ok on a few dialog boxes; the server simply hosts some pretty off-the-shelf cgi.
and it would have some disadvantages - for one thing, customers would have difficulty accessing their accounts from multiple sites, like at home and at work. Not so much that as have a much bigger security issue. Maintaining keys securely would then become a task for the client, and while keeping a written password secret is something most people can handle the concept of, keeping a block of computer data safe from random trojans while exporting it to be transported between machines is much, much harder. Of course, you *could* generate the key entirely locally on the server, protecting it with a HTTPS download, and protect it with the enduser's password (not sure how secure the PKCS password is - if it isn't, then use some self-decoding-exe like the 7z one) but that still wouldn't force the end user to do more than hit "import" and have it stored insecurely on their client machine.
Further, it would require customers to use some features of their browser that most of them have never seen, which is going to be difficult and error-prone for most users. its surprisingly reliable and easy - particuarly if your end users are just using the MS keystore, which requires them to do no more than double-click the pkcs file and hit "next" a few times.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
-- On 7 Jun 2003 at 19:05, Dave Howe wrote:
issuing certs to someone is trivial from both a server and a user endpoint - the user just gets a "click here to request your key" and hits ok on a few dialog boxes; the server simply hosts some pretty off-the-shelf cgi. [...] its surprisingly reliable and easy - particuarly if your end users are just using the MS keystore, which requires them to do no more than double-click the pkcs file and hit "next" a few times.
This sounds more like what I was looking for. Probably someone has already pointed out the url to this, but if they did, I when I looked at it I was snowed under by verisign oriented shit, which assumes a large budget and ample administrator time for face to face contact with certified people, a very small number of clients, some hours of work by each client, a manual, user training, etc, and failed to grasp it. Could you point me somewhere that illustates server issued certs, certification with zero administrator overhead and small end user overhead? Also, I have many times heard that public key operations were surprisingly easy, and have been key administrator for several companies, and have unfailingly found that I was the only person capable of doing these operations at that company. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG v6gZFuZoUgyGH55ME+JoilJSfw5LrufrbWWB454U 4FhiB65yyXwp1RgeJrLADfEYBoqz0YAch8fJ0Fisp --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
James A. Donald wrote:
Could you point me somewhere that illustates server issued certs, certification with zero administrator overhead and small end user overhead? Been a while since I played with it, but IIRC OpenCA (www.openca.org) is a full implimentation of a CA, in perl cgi, with no admin intervention required. Obviously, that involves browser-based key generation. If you want server-based key generation, then take a look at http://symlabs.com/Net_SSLeay/smime.html
If you are iis/asp rather than perl, then there are activex components that will give you access to x509 certificates - EBCrypt is probably the easiest, but there is a activex wrapper for cryptlib too, iirc.
-- James A. Donald:
Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password.
They could not do this using the standard IE webbrowser. They would have to get users to download a custom client, or at least, like hushmail, a custom control inside IE.
Anonymous
Why do you say that? You were already given pointers to how they could configure their web servers to use certificate based client authentication.
That is a solution to a completely different problem. Using that method the administrator would have to set up each client, which is impractically expensive and inconvenient unless administrator and customer meet personally and their computers are in the same office. The point is that the customer should be able to set himself up, as he does on e-gold, hotmail, hushmail, etc, and that if subsequently he is fooled into logging on to a fake site this should do no harm. James A. Donald:
HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time.
Anonymous
HTTPS is just HTTP over SSL/TLS. It says nothing about the trust model for the certificates; it merely specifies how each side can deliver its cert(s) to the other side. Deciding which ones to trust is out of scope for TLS or HTTPS.
You cannot use https to implement the trust model that hotmail and everyone else uses. In that sense it does say something about the trust model. It assumes they are subject to hierarchical validation, which e-gold passwords and hotmail passwords are not. hotmail passwords merely show it is the same guy logging in. You cannot use https to do this. It is designed to show it is the guy blessed by the administrator logging in.
E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so?
Because that is not the trust model they or hotmail want to implement. They don't want true names, and they do not want, and cannot afford, the very great overheads associated with true names. To implement the desired trust model, the client browser would need to generate the private key during account creation. E-gold would then record the corresponding public key. You cannot do that with existing client software. They do not want to turn their business model upside down to support verisign's profit model. The problem is to implement the existing model in a way that protects against the man in the middle attack represented by this storm of fake sites. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG OPeQMye27fygWs3rNrP88mXXiOYU+xcVrAyLlBjO 4+rppNlgtCDm9YfF1Wiqe//vrDa3kdlXpzatLpbhm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
participants (3)
-
Anonymous Sender -
Dave Howe -
James A. Donald