Bug 961539 - RFC: password pam modules for user login based juels_rivest ( or bojinov ) 'pam_honeyword'/'pam_honeychecker' password
RFC: password pam modules for user login based juels_rivest ( or bojinov ) 'p...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
20
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-09 17:13 EDT by collura
Modified: 2015-06-29 07:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 07:56:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description collura 2013-05-09 17:13:26 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 

  and 

  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).  


The paper:

  http://people.csail.mit.edu/rivest/pubs.html

  "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:
    "[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 (?):

  pam_honeyword 
     (generate, mamage honeywords 
      as part of password creation/change)

  pam_honeychecker 
     (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):

 rawhide

How reproducible:

 always

Steps to Reproduce:
1. mouse steals password hashes
2. use of hash to log in allows warningless login
3. mouse takes your profits
  
Actual results:

 little awareness of compromised password file use exists

Expected results:

 increased awareness of use of compromised password file

Additional info:

  neet paper :')
Comment 1 Fedora End Of Life 2013-09-16 09:51:04 EDT
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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 2 Fedora End Of Life 2015-05-29 05:02:55 EDT
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'
of '20'.

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.
Comment 3 Fedora End Of Life 2015-06-29 07:56:43 EDT
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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