[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Re: [GNU Crypto] Passwords Immutable?

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:


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


properties.put(Registry.SASL_PASSWORD, new        

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.


> 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 || csm@xxxxxxx
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
> ZV2gP1JAhbS8UMiPSy4uzHI=
> =qCZs
> _______________________________________________
> gnu-crypto-discuss mailing list
> gnu-crypto-discuss@xxxxxxx
> 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)


This signature file is generated by Pick-a-Tag !
Written by Jeroen van Vaarsel

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/

gnu-crypto-discuss mailing list

[Home]     [Gnu Classpath]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]     [Red Hat 9 Bible]     [Fedora Bible]     [Red Hat 9]     [Network Security Reading]

  Powered by Linux