password-free login without SSL and OP reliance (an anti-phishing solution)

[Douglas Otis]

On Apr 5, 2007, at 3:49 AM, Vinay Gupta wrote:
> On Apr 5, 2007, at 10:40 AM, Douglas Otis wrote:
>
>> Although the world demands GUI, terminal interfaces already offer  
>> a powerful set of tools for doing exactly what is needed.  Public  
>> key cryptography reduces the overhead and security concerns  
>> substantially.  This may also provide an alternative for rather  
>> complex OpenID extensions that will likely over reach with respect  
>> to security.
>
> The literature on both Capability Based Operating Systems and  
> Kerberos should be considered pretty closely here. It's very easy  
> to design systems which are subject to man in the middle attacks  
> and replay attacks, and the semantics of security are equally  
> important (like "what did the user just cryptographically  
> authorize? they thought they authorized access to their name, but  
> the request lied about what it was for...")
>
> Kerberos has an exquisite design for handling network  
> authentication and should probably be considered as a template for  
> subsequent systems. It is old and well examined, and still trusted.  
> Perhaps it would make sense to implement Kerberos over OpenID to  
> solve some or all of these security problems?

To automate secure access between servers, kerberos provides  
centralized access control by containing all client's secrets.   
Shared secrets and a centralized point of failure are sizable flaws  
for large scale deployment.  In addition, OpenID is prone to  
downgrade attacks should acknowledgment become automated.  OpenID  
depends upon phishing prone wet-ware to authenticate URL queries and  
the SSL certificate of the OP.

That said, OpenID overcomes administering replicate signup processes,  
where each user and website is expected to remember user-names and  
passwords.  The user-name/password approach is fairly prone to  
phishing attacks, where OpenID's use of redirection actually  
increases this vulnerability which may then affect all websites that  
the user accesses in this manner.  In addition, without an  
alternative means of access, users are required to maintain a domain  
in order to delegate OPs as a means to ensure continued access. This  
would be very important when an OP is DoS attacked or when an OP goes  
out of service.  Otherwise, OpenID remains a dangerous convenience  
where a user-name/password must still be established as an  
alternative method for each account.

All of these problems are overcome by adding an optional extension to  
OpenID.

For clarity, OpenID Authentication 2.0 - Draft 11 "4.1.1. Key-Value  
Form Encoding" should change to something like "Keyword-Value Form  
Encoding".  Avoid using the word "key" to mean field or label.  This  
will cause confusion.

Here is a rough outline:

1) OpenID defines an OP response field openid.rsa_pub, obtained from  
its user's profile containing a SSH2 public key.

2) The RP may retain this public key and signal the user-agent by  
offering an OpenID key-symbol button for posting a value obtained  
from a "openid.key-auth" URI defining a file whose content verifies  
that the identity of the user-agent has been authenticated in the  
process of obtaining this file.  The size of this file should be less  
that 256 bytes.

3) The user-agent obtains the "openid.key-auth" file's content and  
posts this as a response when the OpenID key-symbol button is  
pressed, instead of the OpenID login button.

This scheme would depend upon the same host and client key pairs as  
used for ssh, scp, sftp, etc.  The following is a hack to allow  
direct utilization of SCP.  The OpenID identity is converted to a  
SHA-1 hash translated to a base64 character string prefaced with  
OpenID.  This would require operating systems able to handle 38  
character user names.  This hash locates a repository for where keys  
are concatenated.  An MD5 hash of the OpenID identity further defines  
the path component below .openid/ for the authentication value.  As  
some point in the future, verification of host and client keys should  
be done in-band.  The location of the "openid.key-auth" should not  
change and be within the RP domain, but this is not a requirement.

When a different OpenID identity is desired to obtain access to an  
account on an RP, the user would still be able to login using the  
OpenID key access method, and then request that the account be  
associated with a different OpenID after verifying the other OpenID  
identity.  This would eliminate the need to delegate OpenID OPs for  
an orderly transition to a different identity.

This method eliminates:
  - redirection for subsequent accesses
  - man-in-the middle attacks
  - continuous dependence upon the OP
  - dedicating a domain for delegation
  - most key entry related threats
  - phishing attacks

To work with Windows, a little putty is needed :)
http://www.chiark.greenend.org.uk/%7Esgtatham/putty/

-Doug