[JDEV] Passwords, zero-K and storage

[DJ Adams]

On Fri, Jun 15, 2001 at 08:35:45PM -0500, Iain Shigeoka wrote:
> It would seem that the only real way of doing this is to store the 
> plaintext password and user name _somewhere_ so you can move records from 
> one authentication system to another.  (storing plain passwords, hashes, or 
> 0k sequences).  At least with the current system.  Now the implementation 
> may encrypt all these passwords so only the server can access them, or 
> perhaps a migration utility in the server, etc... but at some point, 
> somewhere, the plaintext passwords will need to exist.  Otherwise, when you 
> plug in a next generation authentication system, you'll need to have 
> everyone re-send or regenerate their password info.
> 
> Am I missing something?

I don't think so, but I've never spent that much time thinking about
security. To me, requiring a password re-send is less heinous than 
storing the password in plaintext anywhere.

...

> So far this has not been an issue because we've always had the plaintext 
> password on the server which served as the common data format for password 
> information (method 1 with plaintext being the special password storage 
> format... ha ha ha).  It was easy to upgrade to 0k because we could upgrade 
> people on the server using the plaintext password.  However, I expect that 
> many/most would like to use the 0k advantage of no plaintext password at 
> all on the server.  If this is the case, then the next auth protocol (if 
> there will be one) is in for some trouble if we don't address things 
> sometime.

Sure. I guess the concept of wanting to be able to change from one method
to another when the starting method is 'proper' 0k *without* involving the
user simply does not compute.

> <side note>It would be nice nice for server's to be backward compatible and 
> still support digest if not plaintext passwords.  In this case, the 

I'm assuming that the plaintext storage is necessary for digest to ensure
security over the wire (as opposed to on the server) - so that different
tokens can be used to keep the digest 'fresh' and different. That I think
is why mod_plain_digest is merely a 'parasite' on mod_plain_auth - it 
lets it do all the work, except for the glory-bit at the credential checking
stage. 

> suppose we should wait until the Foundation/JEP/JIG etc is all settled 
> first...  *sigh*</side note>

I'm sure that this and other issues that may have fallen between the 
cracks will find a good home with the Foundation and the Jabelin project.
I only wish my JabberC learning would go faster so I could help out more 
:-/

dj