Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1061376 - regenerate password hashes in /etc/shadow if password settings change on next login
Summary: regenerate password hashes in /etc/shadow if password settings c...
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-02-04 17:42 UTC by David Jaša
Modified: 2018-12-20 15:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description David Jaša 2014-02-04 17:42:11 UTC
Description of problem:
The security requirements to password storage may increase over time but currently, when such thing happens, old password hashes are left untouched, providing unnecessary attack vector to the password that may be also used for effectively unbreakable better-encrypted stuff or for online services that employ rate-limiting to protect from brute-force attack.

The user login event is an opportunity that could allow regeneration of the hash should the password requirements tighten at some point of time. Pam could easily check if stored password hash meets criteria in pam configuration and if there is difference, regenerate the hash from password (if the password verification against current hash succeeds of course)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
0. check password hash of some user in /etc/shadow
1. add "rounds=625000" parameter after "sha512" parameter of line in /etc/pam.d/system-auth-ac
2. do a password-verification action as the given user (login, screen unlock)
3. check the /etc/shadow hash again

Actual results:
password hash does not contain rounds=%i parameter (glibc default 5000 is used)

Expected results:
password hash should contain rounds=625000 (translating to ~1s delay on Westmere family processor)

Additional info:
password hash is regenerated when 'passwd' is invocated but passwd blocks regular users from regenerating the hash using the same password, lessening the actual security

Comment 1 Tomas Mraz 2014-02-04 17:49:38 UTC
This is certainly RFE for upstream and Fedora first. Also note that password verification process has/can have different confinement by SELinux policy than password change so it might not be possible to update /etc/shadow during password verification.

Comment 2 Tomas Mraz 2018-12-20 15:22:59 UTC
This is going to be implemented with the switch to libxcrypt in Fedora 30.

Note You need to log in before you can comment on or make changes to this bug.