create & use unique & strong 16 alpha-numeric-special character passwords

Latest response

The scenario is:
I want to create unique & strong 16 alpha-numeric-special character passwords for all my internet based accounts.

The solution I am using is:
Create a function in the .bashrc file as below:
getPasswd() {
DATA=$1
openssl passwd -1 -salt MySalt "${DATA}" |cut -d$ -f4 |cut -c-16 | xclip -sel clip
}

I will call this function from terminal as below:
$ getPasswd abc@abc.com

And the 16 character password will be copied to the clipboard so I can paste it in the password field. This way unique and strong password will be used for each and every account. Every 3 months I keep changing the salt to get new password.

The problem in this solution is if anyone opens .bashrc file, they can see the salt I am using.

Possible solution I think is:
I have another folder which is encrypted using EncFS and I want to put this function in a file called "bashrc" in that folder and only when I mount that folder using EncFS password only then this function should be called. So typically, I have to remember only one password for EncFS folder.

Any suggestions to achieve this (keeping this function in a separate file in my encrypted folder) or to handle this scenario in a better way is welcome. Yes I can pass salt also as a parameter but the command becomes too big to type every time. Also if someone is right next to me looking at the screen, he will know the salt and username from which he can get the password as it is based on standard algorithm. Hence I do not prefer to type the salt every time.

Thanks in advance.

Responses

Looks like the problem is solved. I changed the above command as:
if [ -f ${g} ]; then
openssl passwd -1 -salt $(echo ${DATA} | openssl enc -e -base64 -aes-256-ctr -nopad -nosalt -kfile "${g}") ${DATA} | cut -d$ -f4| cut -c-16 | xclip -sel clip
fi

Start of bashrc file I exported g Path where the passphrase is located. This passphrase file is placed in an encfs folder. So even if the code is in .bashrc file, the passphrase is not known to anyone as it is in an encrypted folder.

Even if they see the salt, the the computation to reverse the hash is a non-trivial task. The related question is "why are you re-using the salt in the first place"? It's as trivial to generate new salts as it is to create new password strings (the same programs - like mkpasswd - can be used for both).

Speaking of mkpasswd: it's a pretty decent utility (part of the expect RPM). You can specify all sorts of parameters around how you'd like the password generated. Overall, it's probably an easier solution than reinventing the wheel.

@Tom, Thanks a lot for the response. Well my intention is never to reinvent it but looks like I have done it. I haven't seen how mkpasswd works. The important point here for me is that when I call the function providing my username as input, it should generate the same password so I can login using that password without even knowing the password. Also it should be platform independent (should be able to use in other flavours of Linux & Windows as well if needed). May be mkpasswd does all that but I haven't explored it.

Also your question "why are you re-using the salt in the first place?" I don't see I am reusing the salt. First I have one salt put in a file (in an encrypted folder which is available only to me). Then using that salt, I am creating separate salts for each account to generate the password. So each and every account will have its own salt and its own password.

Your statement "Even if they see the salt, the the computation to reverse the hash is a non-trivial task." - I don't believe this as I am using pretty open standard. If one knows that my salt is "abcd", replacing "MySalt" with "abcd" in the command posted in my original post, any one in the world can generate the password. The secrecy of the password is as good as the secrecy of the salt in this case. I cannot use same passwords to all the accounts but can use same salt across all accounts and generate separate salts for each and every account and hence the password changes.

Yes, the purpose of the salt is to avoid cracking passwords using rainbow tables, but here the intention is not that. The intention is to generate strong & unique passwords for a given username easily and consistently unless you change the original salt or username.

In the comment I posted, using the salt in the path provided in that file, I am encrypting the username and making it as salt to generate the password for the username. So everytime I give the username, I get the same password as the salt is same. I could have used username itself as salt but that is very easy to guess unless there is something externally I add to it. Hence encryption using an external salt became important.

I hope I explained it more clearly than my original post here.