The following issue has been updated:
Updater: David Le Strat (mailto:[EMAIL PROTECTED])
Date: Mon, 26 Apr 2004 9:22 AM
Changes:
Version changed to 2.0-a1
Component changed to Security
Component changed from Container
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/JS2-13?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-13
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS2-13
Summary: Security Component: Password protection enhancements
Type: New Feature
Status: Unassigned
Priority: Minor
Project: Jetspeed 2
Components:
Security
Versions:
2.0-a1
Assignee:
Reporter: David Le Strat
Created: Thu, 15 Apr 2004 2:58 PM
Updated: Mon, 26 Apr 2004 9:22 AM
Environment: Security Component
Description:
Submitted by Lester Ward.
Password protection features to the
security model used for J2 that will enhance security significantly,
particularly against dictionary attacks on the database.
1) Salted passwords. Protects against batched dictionary attacks.
2) Variable security. Basically a per user settable counter that sets how many times a
hash function is repeated. Repeating the hash does not improve security of a given
password, but rather intentionally slows down the password check and, therefore, makes
dictionary attacks significantly more expensive for the attacker. Further, it can be
tuned per user so that passwords of some users take longer to dictionary attack than
others.
3) Password fields at least large enough to hold hashed SHA-256.
Not as important, but a "nice to have":
4) Variable algorithm. A per user setting that indicates what algorithm is used to
validate the user. This is useful really
only to solve on particular problem: if you later decide to migrate to a new algorithm
-- moving from MD5 to SHA-256, say -- how do you do so without resetting everyone's
password? For most systems, you cannot just rehash the password under the new system,
because you only have the encrypted version and cannot generate the plaintext. If,
however, you had a setting that indicates what algorithm was used, you can do a
migration gradually. That is, next time that user logs on (which is validated under
the old system), you can make him change the password, saving the new one under the
new system. This sounds a bit unlikely, I know, but I've had to migrate two different
systems to a new password algorithm and it was not pleasant because the systems lacked
this feature.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
