Store password response in binary instead of octet string

[GoogleCodeExporter]

This is an enhancement request to store the values to the password response in 
binary instead of Octet String.

Doing so will have the following benefits:
1. Enhance the security of password response answers
I saw that the password response data format is stored in clear. This might 
pose a security risk.

2. LDAP server do not need to extend schema
SUN Directory Server default user attributes do not have Octet String. By 
changing the password response to be stored as binary, I can reuse an existing 
unused LDAP attribute.

What steps will reproduce the problem?
1. Configure password response answers to be saved in LDAP
2. Save password response answers
3. Take a look at the password response value saved in LDAP

What is the expected output? What do you see instead?
Response should be saved in binary. Instead I'm able to see and make out the 
format of the password response.

What version of PWM are you using?
1.5.5

What ldap directory and version are you using?
SUN Directory server 6.3

Please paste any error log messages below:

Original issue reported on code.google.com by anj...@gmail.com on 15 Aug 2011 at 8:12

[GoogleCodeExporter]

1: You can set "Store PWM Responses Encrypted" to TRUE (Configuration Editor 
--> View --> Show Advanced Setting --> Modules --> Forgotten Password). The 
data will be stored using a SSHA hash.

2: Using new attributes with specific names is, in my humble opinion, a much 
cleaner solution than reusing an attribute which originally has another 
purpose. The latter may lead to confusion or conflicts. Sun DS is a very 
reliable directory server and has excellent features to extend the schema 
either through the management interface, using LDAP or local files.

Regards,

Menno Pieters

Original comment by menno.pi...@gmail.com on 15 Aug 2011 at 8:30

• Changed state: NeedInfo

[GoogleCodeExporter]

1: I have already enabled Store PWM Responses Encrypted to TRUE.

I'm not too familiar with encryption/decryption apis. But given the example 
below,

<response adminDefined="true" required="false" minLength="2" 
maxLength="200"><challenge><![CDATA[What is your mother's maiden's 
name?]]></challenge><answer format="SHA1_SALT" 
salt="cPVD5EWWj4Swh1hs4flJOZom09lhQfNL"><![CDATA[yGL/ETrMBrHt5PUVdbBvDHLYWr8=]]>
</answer>

With the salt "cPVD5EWWj4Swh1hs4flJOZom09lhQfNL", does it means its possible to 
decrypt "yGL/ETrMBrHt5PUVdbBvDHLYWr8=" to get access to the answer?

2: I do agree that its cleaner to use new attrbutes with specific names but 
sometimes, customers do not want to extend their schema as they prefer it to be 
clean.

Original comment by anj...@gmail.com on 15 Aug 2011 at 8:56

[GoogleCodeExporter]

1: It is a hash, not two way encryption. The "salt" is not a password, it is a 
starting value for the hash algorithm to make it less vulnerable to certain 
attacks (see http://en.wikipedia.org/wiki/Salt_%28cryptography%29 for an 
explanation). So, no it cannot be decrypted. Only the question is stored in 
plain ASCII, so it can be presented to the user.

2: it all depends on your definitions of "clean" and "abuse". ;-)

Original comment by menno.pi...@gmail.com on 15 Aug 2011 at 9:04

[GoogleCodeExporter]

But by knowing the salt (since its displayed in clear), its still vulnerable to 
dictionary attacks?

Original comment by anj...@gmail.com on 22 Aug 2011 at 10:32

[GoogleCodeExporter]

The existence of the salt eliminates practical dictionary attacks.  The salt is 
always a published value.

You do realize you can change the attribute the response is stored to?  This is 
configured at ConfigManager -> Modules -> Forgotten Password -> ResponseStorage 
attribute.

Storing the value as response will not increase security in any meaningful way. 
 Most ldap browsers would convert it to text very easily. 

So for your enhancement request:

For #1, I disagree that storing as binary provides any increase in security.
For #2, Use of the pwm-defined schema is already not required, you can specify 
any attribute as indicated above.

Closing as WontFix, unless you have other reasons for this enhancement or 
angles I missed, in which case please post them here.

Original comment by jrivard on 22 Aug 2011 at 1:40

• Changed state: WontFix

[GoogleCodeExporter]

Please correct me if I'm wrong as I'm not really an expert in this area.

My understanding is that the hash is a function of the salt+response. If I know 
the value of the salt, I will then be able to apply a dictionary attack on the 
response?

For #2, customer insist that we cannot change their schema. Hence we are using 
an unused attribute of type DirectoryString instead of the required 
OctetString. Seems to work fine.

Original comment by anj...@gmail.com on 23 Aug 2011 at 2:27