I have enabled Linux PAM (version 1.1.4) and cracklib (version 2.8.22) and most things are working fine. All password complexity specified via the PAM configuration file are being adhered to (upper/lower case, digits, etc) but the 'difok' is NOT being adhered to. No matter what I set this option to, pam_cracklib will let any password through (provided it meets the other complexity requirements I've specified).
Long story short I had to modify the Linux PAM cracklib to add some debug and quickly found out that pam_cracklib FAILS to be able to retrieve the OLD password. It thinks the string is NULL so naturally there is nothing to compare the new password to.
Yet when the user changes their own password, it IS CORRECTLY authenticating the current (what will become the OLD) password so pam_unix is correctly seeing the old password. By the time it gets down to the pam_cracklib line of the PAM configuration the password appears to have been wiped out somehow.
I'm pulling my hair out trying to figure out how/where/why this is happening.
Here are the relevant password lines in my PAM configuration file:
password requisite pam_cracklib.so debug reject_username\
minlen=6 ucredit=-1 lcredit=-1 difok=4 maxrepeat=2
password required pam_unix.so debug md5 shadow
BY THE WAY: this is all being done programatically through a front end application. This is NOT something which can be done interactively in this environment.
Does anyone have any ideas on this?
Hashed versions of old passwords are stored in
/etc/security/opasswd
So I would check the perms on that file they normally should read:
-rw-------.
Also (and here is the crux of the issue I think) you have to ad the remember field to the pam_unix module:
pam_unix.so try_first_pass remember=3 use_authtok null debug md5 shadow
Related
Is there a linux command to see the hashed password? Not the actual password but just the hash over it. I have tried showing hash table and such but that has yet to work. Feel like I'm just missing a simple command.
On Unix/Linux systems the hashed passwords of all users are stored into the file /etc/shadow and - for security reasons - this is readable only to root.
Therefore there is no way for an unprivileged user to read its contents.
However, if the NIS service is enabled in your system/network, you can see the hashed passwords in the second column of the output of the command ypcat passwd.
I just noticed I cannot login in my Jenkins.
How can I reset my password and access to my account again? I do not see any link to recover passwords and they seem to be hashed in the installation directory.
In How to reset password of Jenkins you have a set of tricks to make this happen. I based my solution on it, but it diverges in a certain point.
This is what I did to solve the issue:
Let's assume Jenkins' directory is stored in $JENKINS (in my machine this is /var/lib/jenkins/) and your username is user.
Allow signups by disabling disableSignup. This means editing $JENKINS/config.xml and setting this option to false:
<disableSignup>false</disableSignup>
Restart Jenkins (service jenkins restart).
Enter in Jenkins and register a new user, for example testuser, with the password being the one you want to set to your user user.
Extract the hashed password from $JENKINS/users/testuser/config.xml. You will see something like:
<passwordHash>#jbcrypt:$2a$10$PY7p4dxFiGSgJpxiNVTQDuJKAQ8pr9snDgQXaafogjErvgB0oC3qy</passwordHash>
Set the user's password to this one in <passwordHash>. That is, edit $JENKINS/users/user/config.xml and replace the password there to set the one above.
Disallow signups back by enabling disableSignup. That is, in $JENKINS/config.xml set the disableSignup option back to true:
<disableSignup>true</disableSignup>
Restart Jenkins again.
Note you can also replace the password directly by generating a jBCrypt. For example, in http://www.mindrot.org/projects/jBCrypt/ you can find some Java code for it.
A different approach for Windows that solved this issue for me:
In
C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\config.xml, change useSecurity to false.
The restart Jenkins, you will now get full access without login. Go to People, select the old admin user and delete the user.
Then set
<disableSignup>false</disableSignup>
and
<useSecurity>true</useSecurity>
Restart Jenkins again, and you will now be able to register again.
Finally
<disableSignup>true</disableSignup>
To learn the basics of a PAM, I wrote a highly permissive module that returns PAM_SUCCESS for all of the checks (auth, account, password, session). So theoretically, one should be able to login with any username, even those not listed in /etc/passwd, right?
However, it looks like /bin/login performs an account check on its own accord! How do I disable this, so I can let any username login? (for purely theoretical purposes).
My module's log:
pam_sm_authenticate:AUTH request for notinpasswd, allowing it
pam_sm_acct_mgmt:ACCT request, allowing it
Invalid user name "notinpasswd" in pam_open:670. Abort. -- printed by /bin/login
Here is my pam.d/other config:
auth required pam_open.so
account required pam_open.so
password required pam_open.so
session required pam_open.so
Well considering that a user has to have a shell available it may be worth lookimg into using a username that IS real. Have you tried that? If so.let me know and ill dig around but off the top of my head a valid shell and user is required.
I configured msmtp with my gmail account.
I obviously want to avoid writing my password in plaintext format in the config file.
Luckily enough msmtp offer the option passwordeval which can be used to obtain the password from the output of an an executable.
The question is: how should I use it?
I found here the following suggestion:
passwordeval gpg -d /some/path/to/.msmtp.password.gpg
That doesn't make much sense to me: if someone is able to access my config file he will certainly manage to run such a command and obtain the password from gpg.
So I believe I'm left with the only option of obfuscating the password within the binary executable even if I read almost everywhere that this is bad!
My impossible-to-hack implementation is: if the sendmail process is running output the correct pass, otherwise give a fake pass.
Your suggestions?
Other (more secure) tricks different from storing the pass in the binary file?
From Sukima's comment:
The reason gpg -d works is because it requires the private key of the person the file is encrypted to. So just placing that encrypted file in the public it is still encrypted an only one person (the one with the secret key) can decrypt it. It is assumed that the secret key is locked up on the user's machine and not leaked. It also assumes that they have not setup any agents which cache the unlock password while a hacker has direct access to the same machine. All of which is highly unlikely in 99% of all attacks.
There is not a standard solution on how to save credentials with the constraint of
having to use the credentials in plain text later
and in an unattended way
on a system which is not completely controlled by you (if it is you just set appropriate rights on the files holding the secrets)
You have several solutions, none solves perfectly your problem:
encrypt your credentials in a symmetric way: you need to input the key to decrypt them
encrypt in an asymmetric way: you need to provide your private key, which must be stored somewhere (unattended approach) or keyed in
obfuscate: as you mention, this only protects from some population
get it from somewhere else - you need to identify a way or another your system
You need to take into account which risk is acceptable and go from there.
I have a system where users can signup by Facebook or by a regular form. If user signup by Facebook, my system generates a random password, just to allow user to log-in without Facebook if he wants. If user signup using regular form, he can type any password he wants. In both ways, password are encoded into a MD5 hash, but without salting. It's is insecure, I know, this is the reason i'm here.
I don't know the best strategy to convert the passwords into secure ones... First i'm thinking to keep the MD5 insecure password, and when user log-in, i can match the password without salt, salt-it, and then update the database. But it doesn't solve my problem, because system will still accept the insecure password. Besides that, user can still log-in using facebook, witch do not allow me to update their password (since he didn't used it).
So, have anybody an idea to minimize the impact instead of just force everyone to update the passwords?
Thanks!
So, I've done the following actions to solve my problem.
Created a column "LastPasswordChange" in users table.
When user changes password, the field is updated with current date, ALSO, an e-mail is sent to user to inform that password was changed, with a link to revert it in case of this is wrong (due to a possible hack).
The e-mail allow user to log in and set a new password without knowing the last used.
When user log-in using the current password, it looks to the LastPasswordChange field, and if it is null, it allow the login without using the salt.
In any way he/she logs in (Facebook or Login/pass), system looks to the LastPasswordChange field, and if it is null, system requires user to change the current password to a different one (not match the old one without salt).
That's it.