12:52 Passwords for the lazy | |
| Recently, one of the providers, where I rent dedicated servers has been compromised. The damage was quite low, good backups are made daily. On the other hand - to change their passwords on dozens of accounts sleepless night before the holiday is also a lesson in not joyous. The idea of ??automating password changes itching the brain for quite some time, several habratopikov pushed in the right direction. The idea was simple - to change their passwords often as possible (for example - every day) so even if someone and get the password from the correspondence of two days ago - with him nothing could be done. Ideally - the system should generate and change the password immediately before the daily Bacup each account. Easy to say - to automate password changes on a Linux server - I have this bash in your eyes have not seen (not counting bashorga, of course), I do very different things in this life do. However, the technique of breaking up tasks into simple steps, and Google helped solve the problem just in one night. Step one - get the MD5 hash of any string, for example from today: echo-n $ (date +% F) | md5sum The second step - assign the pleasure of some variable, it is better to 2 times longer to obtain (and then show you why): a = $ (echo-n $ (date +% F) | md5sum) & & a = $ {a: 0:32} $ { a: 0:32} Step Three - from the resulting row length of 64 characters we choose, for example, 27 characters from the position number to date (ie if today is August 3, starting from the third position). Thus at 31 days of the month, we are guaranteed to fit into a string of 64 characters (31 + 27 = 58). You can select any other number, the main thing - keep within 64 characters, or make the source string is longer. Hs = $ {a: $ (date +% d): 27} Next, the fourth step - get a list of all accounts on the server. I arranged this version (if someone will offer a more precise - I will be grateful): cat / etc / passwd | grep "/ home" | cut-d:-f1 The hardest part was the fifth step - sorting rows in the resulting list of users. After an hour of experiments I have earned the following (intermediate) version, which shows me the user name and password for the resulting billet: lines = ($ (cat / etc / passwd | grep "/ home" | cut-d:-f1 )) for i in "$ {lines [@]}" do echo" $ i ": $ hs done Obviously, if we simply leave such an option, knowing the algorithm to guess the password is not easy. So I decided to slightly complicate the situation and the sixth step, I looked like this: salt = "abracadabra" lines = ($ (cat / etc / passwd | grep "/ home" | cut-d:-f1 )) for i in "$ {lines [@]}" do echo" $ i ": $ hs s = $ salt" $ i "$ hs newhash = $ (echo-n "$ s" | md5sum) done In other words - are gathered from the current date, hash, we add the account name and "salt", then again count on the hash result. Adding known only to us "salt" we "break" the structure of the algorithm, and adding another account name and we make a hash result unique to each of them. Since we are going to change their passwords every day - give Razgulyai our paranoia and will not do all the passwords the same:) In the search for suitable commands to change the password for the user, I came across a mention of the fact that bash all the moves are recorded. And really, I've found. Bash_history most insolent manner showed me pieces of my experiments. So we had yet to examine the command history and key-in as the seventh step. The eighth step that clearly looked like: cmd = `echo" $ i ": $ newhash | chpasswd` echo $ cmd The ninth and final step was - to gather it all together and add to cron once before running the daily backup. The script something like this: #! / Bin / bash # # Prep some salt salt = "abracadabra" # Calculate hash from today's date and add it to itself a = $ (echo-n $ (date +% F) | md5sum) & & a = $ {a: 0:32} $ {a: 0:32} # Strip 27 characters starting from the character number of today's day of month hs = $ {a: $ (date +% d): 27} # Grab users into array lines = ($ (cat / etc / passwd | grep "/ home" | cut-d:-f1)) # For each user create a new pass with salt + user name + hash # for i in " $ {lines [@]}" do s = $ salt "$ i" $ hs newhash = $ (echo-n "$ s" | md5sum) newhash = $ {newhash: 0:27} # echo "$ i": $ salt "$ i" $ hs: $ newhash # print this out if you want to cmd = `echo" $ i ": $ newhash | chpasswd` echo $ cmd done history-c plainly visible shortcomings: algorithmization strong, ie in the head a password can not be kept are only small letters and numbers, ie Dictionary for sorting small under the distribution of passwords can get your accounts, change passwords that do not need (just not realizing what, but for example one of the servers I have a shell account to use PuTTy as a proxy - I would not want to have the account password is changed every hour). Features: password can be changed as often as desired (if you wish - you can instead of the date use the date / time and change your password every minute or even second) frequent change and compensate for the simplicity of the great length dictionary (only small letters and numbers) knowing the algorithm and the "salt" the password is easy to generate on any machine without fearing for his safety - all the same the next day / hour / minute:) the password will be different Simplicity automation, flexibility (you can always tweak the algorithm by itself) and as a result - a significant savings in time to change passwords for many accounts. Issues: whether a similar way to generate more complicated passwords by using different registers and official character? What other cons are of this implementation? What other advantages there are in this implementation? Is it possible to compensate these disadvantages or even get rid of them (for example, to neutralize the changing of passwords on some accounts you can create a stop-list and throw out of a total list of accounts that have a stop-list)? UPD: The very first comments brought upon the need for clarification. Customers sometimes come into his own account (for example - in cPanel) and that they choose a login / password, and not a login from the certificate. Shell for these accounts are usually turned off at all (with very few exceptions). | |
|
| |
| Total comments: 0 | |