CentOS create a user with predefined MD5 Hashed password
Hi guys.
We are building a certain system where the user register to the website and the same user has to be created on the OS level
The web registration form automatically hashes the password using MD5. the parameters are then passed to a json file.
I can get the password field using jq. I'm wondering however if there's a way to create the user in the system while passing the MD5 hashed password and not the clear text one.
We are building a certain system where the user register to the website and the same user has to be created on the OS level
The web registration form automatically hashes the password using MD5. the parameters are then passed to a json file.
I can get the password field using jq. I'm wondering however if there's a way to create the user in the system while passing the MD5 hashed password and not the clear text one.
I assume you mean SHA512....
You can patch anything in /etc/shadow (first adduser name, then sed -i s/name:!/name:${(password)
You can patch anything in /etc/shadow (first adduser name, then sed -i s/name:!/name:${(password)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you very much for the detailed explanation Daniel McAllister!
Assuming I can get the person building the webfront tp hash the passwords as SHA512,
and output the hash into JSON.
my JSON would now contain the required username, the SHA512 and various other fieldsmy backend needs to later work properly.
What would the user creation process look now?
Assuming I can get the person building the webfront tp hash the passwords as SHA512,
and output the hash into JSON.
my JSON would now contain the required username, the SHA512 and various other fieldsmy backend needs to later work properly.
What would the user creation process look now?
Just curious... why do you need to create server accounts for web users?
ASKER
It's a very complicated System Steve.
The user that's registered on the website will later be able to add certain... processes to teh backend. and we need to make sure that each user can only see the status of his own processes and etc. Some of them will also need Shell access to perform certain things, and as such, we would use the password the provided as the system password.
The user that's registered on the website will later be able to add certain... processes to teh backend. and we need to make sure that each user can only see the status of his own processes and etc. Some of them will also need Shell access to perform certain things, and as such, we would use the password the provided as the system password.
Use a system cron to run/process user addition/deletion from a backend db where your webfront/json will be storing the info.
The cron job would already run with root rights.......
Presumably you built-I strong security to make sure not every web user can create accounts. Note granting users she'll access provides those so intent with an opportunity to compromise...
Where is your md5/hash conversion of user provided plain text password during account creations occurs?
Does it occur in the clients browser or does the plain text password sent to the web server processing via json, etc.
The cron job would already run with root rights.......
Presumably you built-I strong security to make sure not every web user can create accounts. Note granting users she'll access provides those so intent with an opportunity to compromise...
Where is your md5/hash conversion of user provided plain text password during account creations occurs?
Does it occur in the clients browser or does the plain text password sent to the web server processing via json, etc.
ASKER
it occurs on the users side, and we get the hash to the server which then outputs the info into a json.
The json is then read using a script that's called from cron and processed.
My question is this.
How would the useradd command syntax look like if I got the password hashed already.
The json is then read using a script that's called from cron and processed.
My question is this.
How would the useradd command syntax look like if I got the password hashed already.
Depending on the is, the password could be included in the creation using the -p option.
If not, it would require a two step process adduser, usermod -p ...
Do the hash, salt as was pointed out included to the json, presumably salt is randomized on each client?
Though the hash can be used as the salt............
Have not looked at it recently...
To see whether the hash is enough to build the entry that would be added...... And work.
If not mistaken, the first few/several characters of the md5 digest/password is the salt for user input.
If not, it would require a two step process adduser, usermod -p ...
Do the hash, salt as was pointed out included to the json, presumably salt is randomized on each client?
Though the hash can be used as the salt............
Have not looked at it recently...
To see whether the hash is enough to build the entry that would be added...... And work.
If not mistaken, the first few/several characters of the md5 digest/password is the salt for user input.
What you're asking the system to do is a violation of all of the security protocols you can think of.
-- Daniel McAllister
I understand the desire to automate things like this, but I can't help but feel this is horribly, horribly wrong.
- Web user accounts and system accounts will have the same password.
- Allowing web users to create (and own!) arbitrary server processes.
- This has been done (again, see cPanel, Plesk, et al), and it turned out to be as much of a bad idea as it sounds.
I know... this isn't what you want to hear, and you're probably going to go ahead and do it anyways because you already have it in your head that this idea is an awesome time-saver for *everyone* involved. I'd just like to bring two other points to help you stop and reflect:
1. The original email specification has no facility for communication security because it existed in an academic vacuum. In fact, the idea of adding basic security features was actively rejected as unnecessary.
2. At some point in our history, when someone stood up in a creative meeting and said, "HEY! Let's make a movie about a tornado filled with sharks!", someone else heard that and thought, "What a brilliant idea!"
Good luck!
By the way, all the MD5 utils I've tried create a 32-character hash, not 22.
e.g. http://slavasoft.com/hashcalc
e.g. http://slavasoft.com/hashcalc
Steve, do not disagree with your sentiment, but as you noted, the asker is not receptive to comments from dissuading the pursuit.
Depending on what is being considered to run on the system as a service, possibly a mailing/list distribution, etc. that the asker wants to be identifiable .....
There are techniques/schemes that one can use virtual users under whose credentials some features are run that are not granted system level access....
Depending on what is being considered to run on the system as a service, possibly a mailing/list distribution, etc. that the asker wants to be identifiable .....
There are techniques/schemes that one can use virtual users under whose credentials some features are run that are not granted system level access....
ASKER
With Respect Steve.
There is a right way to approach anything. Especially asking a question that for all you know could be entirely purely academic.
but if you MUST know, this system will server an in-house ONLY system that is inaccessible to anywhere besides the lab it's installed it (a physical lab mind you) which is not connected to any other physical switch outside the lab (Literrally isolated, not logically, there is not a single cable that runs oput fo that room!) Information to and from that machine is going through a NAC with MAC filtering that will only accept input from machines that are preinstalled in this lab. The computers in the lab will completely power off if not used for over 15 minutes, the hard drives are encrypted and are tagged with an RFID chpis that will trigger security warnings if taken our from the lab (security warnings that bring armed guards that is)
Oh and the "arbitrary" processes are mathematical calculations regarding protien folding (or whatever that means, I'm no biologist nor a chemist) to make drugs that inoculates people from cancer. So while I thank you for your ensightfulness and since you were so kind to remind me of two things, I shall return the favor.
1) Never EVER assume you are correct unless you know for a fact you have all the information regarding a case.
2) Even if you know you are right, being an absolute ASS about it and degrading others, won't make your point any more welcomed or valid than it might have been otherwise.
There is a right way to approach anything. Especially asking a question that for all you know could be entirely purely academic.
but if you MUST know, this system will server an in-house ONLY system that is inaccessible to anywhere besides the lab it's installed it (a physical lab mind you) which is not connected to any other physical switch outside the lab (Literrally isolated, not logically, there is not a single cable that runs oput fo that room!) Information to and from that machine is going through a NAC with MAC filtering that will only accept input from machines that are preinstalled in this lab. The computers in the lab will completely power off if not used for over 15 minutes, the hard drives are encrypted and are tagged with an RFID chpis that will trigger security warnings if taken our from the lab (security warnings that bring armed guards that is)
Oh and the "arbitrary" processes are mathematical calculations regarding protien folding (or whatever that means, I'm no biologist nor a chemist) to make drugs that inoculates people from cancer. So while I thank you for your ensightfulness and since you were so kind to remind me of two things, I shall return the favor.
1) Never EVER assume you are correct unless you know for a fact you have all the information regarding a case.
2) Even if you know you are right, being an absolute ASS about it and degrading others, won't make your point any more welcomed or valid than it might have been otherwise.
ASKER
Thanks a lot for the insights.
We did eventually change to SHA512 and used a randomizing salt.
and we were able to implement the changes into our system. Thanks
We did eventually change to SHA512 and used a randomizing salt.
and we were able to implement the changes into our system. Thanks
>>> 1) Never EVER assume you are correct unless you know for a fact you
>>> have all the information regarding a case.
I was not assuming I was "correct" - there was no question for which I could be right or wrong. Nor did I believe I had all the information about the case - I was presenting the argument that your desired course of action is inherently unsafe, regardless of other facts of the case. It is easy to rationalize with the argument of a closed system...what could go wrong with such isolation? Hrrmm... ask Iran about Stuxnet. Your rationalization does nothing to impact the dangers associated with this strategy.
>>> 2) Even if you know you are right, being an absolute ASS about it and
>>> degrading others, won't make your point any more welcomed or valid
>>> than it might have been otherwise.
I was not being an ass. In fact, I was trying to illustrate the problem and define the reasons as gently and as humorously as possible. Nothing in my post degraded you, nor was it meant to. My intention was "informed consent", so to speak, in that if you want to move forward on a potentially dangerous strategy, you should definitely be aware of the danger. My apologies if your self-righteousness got in the way of hearing my argument for what it was.
Still, good luck!
>>> have all the information regarding a case.
I was not assuming I was "correct" - there was no question for which I could be right or wrong. Nor did I believe I had all the information about the case - I was presenting the argument that your desired course of action is inherently unsafe, regardless of other facts of the case. It is easy to rationalize with the argument of a closed system...what could go wrong with such isolation? Hrrmm... ask Iran about Stuxnet. Your rationalization does nothing to impact the dangers associated with this strategy.
>>> 2) Even if you know you are right, being an absolute ASS about it and
>>> degrading others, won't make your point any more welcomed or valid
>>> than it might have been otherwise.
I was not being an ass. In fact, I was trying to illustrate the problem and define the reasons as gently and as humorously as possible. Nothing in my post degraded you, nor was it meant to. My intention was "informed consent", so to speak, in that if you want to move forward on a potentially dangerous strategy, you should definitely be aware of the danger. My apologies if your self-righteousness got in the way of hearing my argument for what it was.
Still, good luck!
are you using the usermod option with -p 'encrypted password' or are you scripting editing of /etc/shadow? locking is required to make sure you do not have two changes going at the same time....
You just need to patch shadow with password after legitimate useradd/adduser.
You could also generate SSH keys per web user and log in accounts remotely (less variable content from the web and less dangerous root actions)
You could also generate SSH keys per web user and log in accounts remotely (less variable content from the web and less dangerous root actions)
Do you have other options? You can have centrally managed user MYSQL, postgresql backend for user............. openldap
Since the clear text password is likely being transmitted via the web request, ......