Red Hat Bugzilla – Bug 961539
RFC: password pam modules for user login based juels_rivest ( or bojinov ) 'pam_honeyword'/'pam_honeychecker' password
Last modified: 2015-06-29 07:56:43 EDT
Description of problem:
To increase account login security and to warn of use of stolen password file.
Evaluate and implement a Juels_Rivest honeyword password capability
(or possibly the Bojinov kamouflage honeyword capability)
in the pam authentication process of user login.
The purpose of the honeyword use as part of the login procedure would be:
a) to attach more effort to an attempted breakin and to alert the system to a compromised password file
b) to give the system under attack a signal to tighten its security during a current attack (allowing trigger for system lockdown or increased logging or attempt traceback).
"290. [JR13] Honeywords: Making Password-Cracking Detectable.
Ari Juels and Ronald L. Rivest.
(2013-05-02) Unpublished draft."
( or possibly related paper listed as jeuls_rivest reference #6:
" H. Bojinov, E. Bursztein, X. Boyen, and D. Boneh.
Kamouflage: loss-resistant password management.
In ESORICS, pages 286–302, 2010."
discusses an approach for system alert of a breach of the password file hashes.
An enterprise version of this would put the honeychecker on a seperate hardened system (specificly called for in paper).
Though a test version of this system (no seperate honeychecker system(?), not advised by paper) might instead put honeychecker on the same system (?)
As an alternative might implement part of the scheme as Bojinov kamouflage (?)
which might still provide some increased security (?) to the login procedure.
I disclaim knowing a correct way to implement this as part of the login process but expect something like the following.
2 components would be required by the paper (?):
(generate, mamage honeywords
as part of password creation/change)
(check validity of password
as part of login process
and generate alarm if user trying
to login with a honeyword
instead of with the password)
During the password checking duty of a user login
the pam_unix module would call (?)
the proposed "pam_honeychecker" module as a helper
in place of calling unix_chkpwd to do the actual password checking (?).
If the login attempt used a honeyword
instead of the password
then an alarm is set and login is denied
and other logins locked down pending password changes.
Instead of just disallowing the attacker from
logging in to the compromised account
the alarm status could be used to
log the attacker into a honeypot account for monitoring.
(Jeuls_Rivest section 6.2 Failover in the paper
suggests that if the honeychecker system is unreacheable
that honeywords would be promoted to useable passwords
so that users could still login. The idea being that
the system would be no less secure that it was
without the the honeyword implementation. This seems like
an obvious attack vector and it might be nice to have the option
of just denying login if honeychecker isnt available
if the admin sees fit but that might depend on
how long the outage might last?)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. mouse steals password hashes
2. use of hash to log in allows warningless login
3. mouse takes your profits
little awareness of compromised password file use exists
increased awareness of use of compromised password file
neet paper :')
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.
More information and reason for this action is here:
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.