If I may inject my humble opinion(that isn't necessarily a response to this peticular email), I may not be as informed as some but....

While I admit that PKI is flawed, I don't see anyway that PSK could used effectively.

How are PSKs going to be shared in a secure way?
are we talking about generating a new key for every connection?
    if so how do you validate the key?
    if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site?
In my opinion, PSK has the same problems as all symmetric encryption, its great if you can share the secret securely, but distribution to the masses makes it infeasible.

>From the way I see it, if site logins were done using a client certificate, like the USPS electronic postmark site allows and should enforce, then the security issues wouldn't be issues, as there would be nothing usable handed off to an attacker. Furthermore the site could be sure of the users identity, something none of the other solutions I have seen address.

Pengdows eMail Signature
 Alaric Dailey Everyone deserves privacy.
Thawte ‘Web of Trust’ Notary Seal Thawte ‘Web of Trust’ Notary
CAcert ‘Web of Trust’ Assurer
Notary Public
CAcert ‘Web of Trust’ Assurer Seal
Some versions of these products have trouble replying to digitally signed emails, like this one.
For more information on this error, and how to fix it please visit Mark Nobles website here.

Stephan Neuhaus wrote:
James A. Donald wrote:
But does not, in fact, prevent.

Let me rephrase that.  Are we now at a point where we must admit that PKI isn't going to happen for the Web and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs?  If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance.

That's because PSKs (as I have understood them) have storage and management issues that CA certificates don't have, four of which are that there will be a lot more PSKs than CA certificates, that you can't preinstall them in browsers, that the issue of how to exchange PSKs securely in the first place is left as an exercise for the reader (good luck!), and that there is a revocation problem.

To resolve any of those issues, code will need to be written, both on the client side and on the server side (except for the secure exchange of PSKs, which is IMHO unresolvable without changes to the business workflow).  The client side code is manageable, because the code will be used by many people so that it may be worthwhile to spend the effort. But the server side?  There are many more server applications than there are different Web browsers, and each one would have to be changed.  At the very least, they'd need an administrative interface to enter and delete PSKs.  That means that supporting PSKs is going to cost the businesses money (both to change their code and to change their workflow), money that they'd rather not spend on something that they probably perceive as the customer's (i.e., not their) problem, namely phishing.

Some German banks put warnings on their web pages that they'll never ask you for private information such as passwords.  SaarLB (http://www.saarlb.de) even urges you to check the certificate fingerprint and provides well-written instructions on how to do that. In return, they'll assume no responsibility if someone phishes your PIN and TANs. They might, out of goodwill, reimburse you.  Then again, they might not.  I believe that SaarLB could win in court.  So where is the incentive for SaarLB to spend the money for PSK support?



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to