Posted on 02/08/2018 6:16:47 AM PST by Voption
A survey of computer security experts confirms that they generally consider Linux superior to either the Windows or Apple operating systems when it comes to security....And if you want to try out Linux, all you really need is a spare laptop or desktop, one or two years old, that you aren’t using any more, and to then follow the instructions provided here on Behind the Black by reader James Stephens for Getting and Installing Linux."
(Excerpt) Read more at behindtheblack.com ...
TPM is no stronger than the underlying security library.
https://thehackernews.com/2017/10/rsa-encryption-keys.html
I would not say that Pen testing and password cracking are two different things. Rather, I am of the opinion that password cracking is a sub-set of Pen testing.
When IT Pros are asked by their relatives what computer they should buy, the answer is always the same: Buy a Mac and get AppleCare. Why? Because that way the pros will sleep at night instead of playing tech-support for Aunt Martha or Uncle Fred.
Thanks for those links. They all certainly validate what you are doing, but all of them are obtaining hashes one client victim at a time. I had in mind obtaining all the hashes in bulk which used to be a problem on older versions of windows. From my quick read some of the hash revealing by legacy modes (e.g. LM Hash) is to take your advice and use at least a 15 character password. I always wondered why so long, now I know.
Thanks for that link. I see the vulnerable keypair generation library made it into some TPM chips. I wrote an RSA keypair generation library once as an experiment. I’m sure it had a ton of vulnerabilities. If I have one (haven’t checked yet) I should be able to reflesh it.
I agree the external hash capture on Windows makes it a subset of pen testing. But I’m not sure pen testing includes cracking on other systems e.g. locked down Windows server (which I am not super familiar with) or Linux servers, web servers, and associate password frameworks which I am more familiar with. In those cases you need to penetrate to get to the hashes. Most passwords are being sent HTTPS and the hashes are calculated and compared on the server, so you have to be there or break HTTPS or sniff victim keyboards, or put a camera in each victim’s office, and go for the cleartext password.
Amazing. Ever read this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.4474&rep=rep1&type=pdf
A while back (8+ years I think) I did a web scan for a customer and found that the web server was running on a SCO box (I think). The web server was vulnerable to a directory traversal attack and through that, I was able to read the /var/spool/backup directory. At least that is the directory as I remember it.
It was there that I found a copy of the /etc/shadow file as the admin had used the root account to run a script that read and parsed information from the /etc/shadow. The script wrote the output to a temp file and, I assume, did something with the content of the temp file.
Granted a very poor sysadmin but you never know. Many admins are not as skilled as they claim or as they should be.
“No, it is not”
You’re probably thinking that a checksum is generated on the fly as a data stream goes by. Thus checksum generation must be speedy, and checksums are short. I’m thinking that a hash is formed from a relatively small amount of data (the password) using a more time consuming algorithm.
"Fascinating," I say, raising an eyebrow.
Hmmm. So if the hacker knows how this encryption scheme, and can find the encrypted password within the computer, he can compute the correct password.
The encryption is one-way. That is to say, if you have the output of the encryption function, it is no better than guesswork to obtain an input that will produce the same output. Even if you have the source code for the encryption function.
E.g., SHA1 is a one-way encryption function. SHA1('cymbeline') is 'ad80554e95fbaff9f3a28d99347f737d7d3ba419'. Your task is to come up with some input to SHA1 that will produce the identical output. It could be 'cymbeline' or something else. But your task is to find it.
So, let's consider an example ...
User root suspects his password has been shoulder-surfed, and he therefore needs a new one. He picks cymbeline.
At this point, most security types would cringe. Only nine characters! Only lower-case letters! Only 5,429,503,678,976 possibilities. Why, some Russian with a GPU rig could brute-force that in hours at most!
But our buddy root presses on. He commands the password change. At that point, his computer picks a random salt, say 104386a3892cab103dc6c4f106aa94937a9d0098, concatenates it to the chosen password and computes SHA1 of the result:
SHA1('cymbeline104386a3892cab103dc6c4f106aa94937a9d0098') =Two items go into the password database for root: the salt and the above-calculated SHA1 hash.
'f66b7529b852fb52ae2bc1b94549a847b4794db3'
When root later attempts a logon, the system appends root's salt to the entered password, calculates SHA1 of the result and compares it to the value in the database.
If there's a match, root is on. If not, the system responds with a curt login incorrect, imposes a delay of a second or so, and reprompts for login.
Is this secure?
Obviously, if attackers are restricted to accessing the login page and guessing passwords, it is highly secure. After all, 5,429,503,678,976 / 2 / (86400*365.25) = 86,025 years on average to guess the password (and that's assuming they know root is addicted to 9-character lowercase passwords).
But suppose the hackers have compromised the server and somehow have obtained a copy of the password database without being root. Then they know the salt and the SHA1 of the password plus the salt. Then the task is to guess a password that, when the salt is concatenated and the SHA1 is calculated will result in the value stored in the database. Say their GPU array can test a billion per second. Then the calculation is 5,429,503,678,976 / 2 / 1e9 = about 45 minutes.
Those are two very different threat models. In the first, it is assumed the password database has not been compromised, and interacting with the host is the only way in. In the second, we assume the enemy has the password database but has not keylogged root's password reset command. Thus, the enemy must guess it in order to get in through the front door. But we've already assumed they got in through the back door, so why bother? I mean, root owns the password database, and, if it's been compromised, then the security of his password is the least of his worries!
The second threat model is much more amenable to click-bait articles than the first.
“Say their GPU array can test a billion per second”
Wow! That’s serious computing. Your posts have been enlightening, but many of our fellow posters would consider us off topic, so enough for now.
Thanks to you and others, I now know more about password encryption.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.