2014-11-26 13:26 EST

View Issue Details Jump to Notes ] Wiki ]
IDProjectCategoryView StatusLast Update
0012957mantisbtldappublic2014-09-23 18:05
Reporterscmme 
Assigned To 
PriorityhighSeveritytweakReproducibilityhave not tried
StatusacknowledgedResolutionopen 
Product Version1.2.5 
Target VersionFixed in Version 
Summary0012957: Password stored md5-unsalted in database when LDAP authentication is enabled
DescriptionWhen LDAP authentication is enabled the password field in the database will automatically update upon login. This is helpful for systems where the authentication system may be migrated from LDAP to local, but is unnecessary in environments where LDAP is a strict requirement. It exposes additional information in an insecure manner (md5 + no salt).

This behavior should be at least configurable if not stored in a more secure manner.
Steps To Reproduce0. Configure LDAP Authentication / Create a user with valid LDAP credentials
1. update $c_user_table set password = '' where username = 'user'; commit;
2. Login as user with valid credentials
3. select password from $c_user_table where username = 'user'
4. Take note of value 'password'
Additional InformationMinor patch would be to:
Modify function ldap_authenticate_by_username in core/ldap_api.php to wrap the user_set_field password call to require a configuration item, eg:
                        if ( ON == config_get( 'ldap_db_pwd_autoupdate' ) ) {
                                user_set_field( $t_user_id, 'password', md5( $p_password ) );
                        }

Document new variable and set it in configuration.
Tagspatch
Attached Files

- Relationships
related to 0015721closedgrangeway Functionality to consider porting to master-2.0.x 
+ Relationships

-  Notes
User avatar

~0028743

scmme (reporter)

This issue also occurs when a user is created.
User avatar

~0031127

grangeway (reporter)

The version of the ldap api in our next branch [which supports multiple servers] doesn't store the password locally. Storing an LDAP password locally is really a security risk IMO.
User avatar

~0031466

atrol (developer)

Reopened, there is no "Fixed in Version" and we will have no "Roadmap" and "Changelog". There is no patch / changeset attached which will confuse any user who has a look at this issue.
User avatar

~0033292

grangeway (reporter)

this is fixed in the mantis-2.x branch
User avatar

~0036219

grangeway (reporter)

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch
+  Notes

- Issue History
Date Modified Username Field Change
2011-04-21 12:16 scmme New Issue
2011-04-21 14:02 siebrand Priority normal => high
2011-05-03 21:32 scmme Note Added: 0028743
2011-05-24 05:00 vboctor Tag Attached: patch
2011-05-24 05:00 vboctor Assigned To => vboctor
2011-05-24 05:00 vboctor Status new => acknowledged
2011-05-24 05:00 vboctor Assigned To vboctor =>
2012-02-05 07:38 grangeway Note Added: 0031127
2012-02-05 07:38 grangeway Status acknowledged => resolved
2012-02-05 07:38 grangeway Resolution open => no change required
2012-02-05 07:38 grangeway Assigned To => grangeway
2012-02-22 16:16 atrol Status resolved => closed
2012-03-14 18:20 atrol Note Added: 0031466
2012-03-14 18:20 atrol Status closed => feedback
2012-03-14 18:20 atrol Resolution no change required => reopened
2012-10-20 20:00 grangeway Note Added: 0033292
2012-10-20 20:00 grangeway Status feedback => resolved
2012-10-20 20:00 grangeway Fixed in Version => 1.3.x
2012-10-20 20:00 grangeway Resolution reopened => fixed
2013-04-05 17:56 grangeway Status resolved => acknowledged
2013-04-05 17:56 grangeway Note Added: 0036219
2013-04-05 18:56 grangeway Relationship added related to 0015721
2013-04-06 09:26 dregad Tag Attached: 2.0.x check
2013-04-06 09:26 dregad Status acknowledged => resolved
2013-04-06 10:32 dregad Assigned To grangeway =>
2013-04-06 10:32 dregad Status resolved => acknowledged
2013-04-06 10:32 dregad Resolution fixed => reopened
2013-04-06 10:32 dregad Fixed in Version 1.3.x =>
2013-04-06 15:18 grangeway Status acknowledged => resolved
2013-04-06 15:18 grangeway Resolution reopened => fixed
2013-04-06 15:18 grangeway Assigned To => grangeway
2013-04-27 16:34 atrol Assigned To grangeway =>
2013-04-27 16:34 atrol Status resolved => acknowledged
2013-04-27 16:34 atrol Resolution fixed => open
2014-09-23 18:05 grangeway Tag Detached: 2.0.x check
+ Issue History