directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Moyer <smo...@psu.edu>
Subject Re: Password as String or char[]?
Date Mon, 10 Oct 2016 18:49:11 GMT
I've seen the same security recommendations related to passwords being long-lived in memory
so I'm curious to hear how what you'd like the XML to look like.

Steve

“Object-oriented programming is an exceptionally bad idea which could only have originated
in California.” – Edsger Dijkstra

----- Original Message -----
From: "Kiran Ayyagari" <kayyagari@apache.org>
To: fortress@directory.apache.org
Sent: Monday, October 10, 2016 1:31:06 PM
Subject: Re: Password as String or char[]?

On Mon, Oct 10, 2016 at 10:53 PM, Shawn McKinney <smckinney@apache.org>
wrote:

> Hello,
>
> recently a question came up that brought up an old question.  How should
> the password be represented in code.
>
> Here is how it is now:
>
> public class User extends FortEntity implements Constraint, Serializable
> {
>     private String userId;
>     private char[] password;
> …
> }
>
> I changed it to a char[] years ago due to perceived concerns wrt security,
> and the immutability of Strings staying resident in memory until GC’d.
>
> But this creates difficulties when squirting into / out of xml in fortress
> rest function.  For example here is how the password is sent over the wire:
> > <FortRequest>
> >     <contextId>HOME</contextId>
> >     <entity xsi:type="user"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >        <userId>test</userId>
> >        <password>112</password>
> >        <password>97</password>
> >        <password>115</password>
> >        <password>115</password>
> >        <password>119</password>
> >        <password>111</password>
> >        <password>114</password>
> >        <password>100</password>
> >     </entity>
> >  </FortRequest>
>
>
> which smells really bad.  I propose we change it back to a string as the
> risk in nominal and not worth the trouble.
>
> Thoughts?
>
+1 to change it to string. We can always explicitly mark that as "null"
after using it.

(IMO if the attacker gained access to the OS then we have a bigger
operational security issues than
implementation)


> Shawn
>
>
>
>
>
> Kiran Ayyagari

Mime
View raw message