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. |
|
|
|
ATTENTION
USERS OF MICROSOFT OUTLOOK AN MICROSOFT OUTLOOK EXPRESS:
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?
Fun,
Stephan
|
smime.p7s