Re: An attack on paypal
James A. Donald wrote: How many attacks have there been based on automatic trust of verisign's feckless ID checking? Not many, possibly none. I imagine if there exists a https://www.go1d.com/ site for purposes of fraud, it won't be using a self-signed cert. Of course it is possible that the attackers are using http:// instead, but more people are likely to notice that. That is not the weak point, not the point where the attacks occur. If the browser was set to accept self signed certificates by default, it would make little difference to security. I don't think any currently can be - but regardless, an attacker wishing to run a fraudulent https site must have a certificate acceptable to the majority of browsers without changing settings - That currently is the big name CAs and nobody else.
Re: Maybe It's Snake Oil All the Way Down
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.
Re: Maybe It's Snake Oil All the Way Down
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.
Re: Maybe It's Snake Oil All the Way Down
At 10:09 AM 6/2/03 -0400, Ian Grigg wrote: (One doesn't hear much about crypto phones these days. Was this really a need?) As a minor aside - most laptops can manage pgpfone using only onboard hardware these days, either using an integrated modem or (via infrared) a mobile phone.
