gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Crypto] Passwords Immutable?


From: Bryan Hoover
Subject: Re: [GNU Crypto] Passwords Immutable?
Date: Wed, 14 Apr 2004 03:58:44 -0400

Casey Marshall wrote:
> What I would probably do is introduce some new classes, e.g.
> 
> public final class Password {
>   private final char[] password;
>   public Password (char[]);
>   public char[] getPassword();
>   public void destroy();
> }

I implemented this (including the Destroyable interface), and changed
SRPClient as follows:

this.password = 
  ((Password) properties.get(Registry.SASL_PASSWORD)).getPassword();

I changed SaslConnection as well:

From:

properties.put(Registry.SASL_PASSWORD, userInfo.substring(ndx+1));

To:

properties.put(Registry.SASL_PASSWORD, new        
passWord(userInfo.substring(ndx+1).toCharArray()));

Attached are Password.java, and patches for SRPClient, and
SaslConnection.  The patches are relative anoncvs 4/14 at around 9:15am
GMT.  I recompiled gnu-crypto.jar, and incorporated the Password class
in the project I'm working on.  It tested fine.

Of course, this doesn't do anything about the SaslConnection constructor
parameter -- a URL variable containing the password in the url string. 
But the SaslConnection object is not really a part of library -- it's
just an example interfacing with the lib, and the patch effects its
SRPClient call in this regard.

SRPClient callers such as that exemplified by SaslConnection would be
broken without changes to their password property setting code.

One alternative is a new password property to hold the Password object,
instead of SASL_PASSWORD, so SASL_PASSWORD would still work with String.

I wasn't sure whether the Password class should make a copy of the
char[] password passed to the constructor.  Not copying ensures the only
copy gets zeroed -- doesn't leave it up to the caller to zero it -- so I
didn't copy it.  I noticed, not making a copy seems to be in line with
what the assignment from the password callback in SRPClient does, and
also it's in line with what Password.getPassword does.

There is a question about whether SRPClient should use Password, or
char[], or only store in the HashMap property, the Password object.  I
assumed only the HashMap storage, but obviously, this can be changed
without api ripple effects.

So there may be a couple of minor implementation questions:

1.  Should Password make a copy?

2.  Should SRPClient this.password be char[] or Password?

Finally, I wasn't sure whether to throw an exception on password access
attempts subsequent to calling destroy().  I do not.

Sorry so wordy.

Feel free to use or not -- though I hope you will.  I can also add the
code to pivot (and whatever else) relative to which password property
use if you want to go with the additional property option for
compatibility.  I had fun doing it, and will use it in my compile.

Bryan

> 
> Which makes more sense than a char array, and even kind of makes more
> sense than a String. The sensitive data is immutable, but erasable,
> and it is wrapped in an object that is sensible for it's purpose.
> 
> There's also the javax.security.auth.Destroyable interface, which any
> JVM worth it's salt should be written to respect.
> 
> - --
> Casey Marshall || address@hidden
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
> 
> iD8DBQFAewz4gAuWMgRGsWsRAnRAAJ9ie3a8EJYmhYMIPCPotLv6nxvBZQCcCGvG
> ZV2gP1JAhbS8UMiPSy4uzHI=
> =qCZs
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> gnu-crypto-discuss mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gnu-crypto-discuss

-- 
I depict hope so vividly that every hopeful individual will recognize
himself in my portrayal; and yet it is a fake, for while I depict it I
am thinking of recollection. - (Soren Kierkegaard - Either/Or)

http://www.wecs.com/content.htm

This signature file is generated by Pick-a-Tag !
Written by Jeroen van Vaarsel
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=pick-a-tag

Attachment: SRPClient.patch
Description: application/unknown-content-type-patch_auto_file

Attachment: SaslConnection.patch
Description: application/unknown-content-type-patch_auto_file

Attachment: Password.java
Description: java/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]