how to ensure that my Linux password can't be cracked by any user or even superuser
 

prasanta7dutta@gmail.comhow to ensure that my Linux password can't be cracked by any user or even superuser

Use a good password?

It is relatively difficult to crack any one way hash... especially now with the more advanced hash functions.

dictionary attacks are easy - but useless against good passwords.

Passwords are stored as salted hashes, and as long as the password is strong and the operating system isn't spying on you, the only way to crack the encryption is via brute-force methods. For a reasonably strong password and a modern hash algorithm, this just isn't feasible.

However, the superuser doesn't have to crack your password in order to gain access to your local account.

You don't need to crack the password. root can reset the password or su to the user without supplying the password. Neither of which tells them what the password is, but functionally it's not needed. They can also clone the system to other hardware and devote all of that machines efforts to brute forcing the password if they wanted to.

Strange that you are concerned about your password, but willing to put your email address on a public forum!

every password can be cracked. probably it will take time, but it is not impossible. Therefore you need to change your password time by time...

You can't, and the superuser doesn't have to 'crack' your password, since they can just CHANGE IT whenever they'd like. And no one here is going to email you answers...this is a community forum, so unless you participate in the forum, you won't get answers.

Maybe that is his password?

Just be sure not to use "password" as your password. Use "password123" instead. That makes it super-secure. :D

Even if you encrypt your stuff, and want to keep that data out of root's hands, you will fail. root can view raw memory, put keyloggers on you, etc. If root is patient, persistant and knowledgeable enough, you have already lost before you even get started.

See:
http://www.thegeekstuff.com/2008/06/...ong-passwords/
There's also rule 3, deducibility: Don't use you date of birth or any number or data from your personal information, which is rather easy to come by. And rule 4, change it often in case they are brute-forcing it.

Avoid common passwords, and there are many lists online of the most common passwords.

None of this can guarantee that your password can't be cracked, but it will make it less likely.

While this may be technically correct, cracking a hash created with an algorithm without known vulnerabilities would literally take ages. Consider this little thought experiment:

• a user has a complex password of unknown length that's not a common dictionary word
• the password is hashed with SHA1 using a random salt

Since the password isn't vulnerable to a dictionary attack and may be any length, the attacker would have to resort to brute-force cracking.

A SHA1 hash is 160 binary digits long. That means there are 2^160 possible hashes. If that doesn't sound like a lot, here's the full 49-digit number:

1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976

I don't know how fast one can generate SHA1 hashes, but let's go out on a limb and assume the attacker has full access to all the resources in both the Microsoft Azure and Amazon Elastic Cloud environments. Let's say the combined efforts of these systems can generate a mind-numbing one quintillion hashes (1,000,000,000,000,000,000 hashes) per second (which I'm pretty certain they can't, not by a long shot).

Let's further assume that the attacker only has to search through half the keyspace before a matching hash is found. He'll then have cracked the password after roughly 730,750,818,665,451,459,101,842,416,358 seconds, which is a little over 23 sextillion years. By then, the hacker will have had to deal with some other pressing issues, such as the heat-death of the universe.

TL;DR: Brute-forcing hashes is really hard work, which is why most attacks against encryption algorithms are based on cryptanalysis, exploiting weaknesses in the algorithm itself.

There's a lot of assumptions there. First we are assuming that LOGIN_RETRIES is sensible. If your password is '12345' or 'password', then a dictionary attack is viable i.e. you'll guess the password before you run out of tries.

For the hash algorithm used by shadow, you can check '/etc/shadow' to see what hash is used:
http://dietrichschroff.blogspot.com/...passwords.html
I know Slackware uses $5$ which is SHA-256, but outdated distros may use $1$ (MD5), which is rather broken. However, the salt greatly improves the security.
http://ehash.iaik.tugraz.at/wiki/The_Hash_Function_Zoo
http://en.wikipedia.org/wiki/Cryptog...ash_algorithms

Or the use of rainbow tables...

Generating the hash is slow... but searching a pre-existing list is much faster (I think a radix search is the fastest).

The problem is that storing 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 different hashes is still a bit hard.

Not to mention that someone would still have to generate the rainbow table first.

Rainbow tables are usually created based on (permutations of) dictionary words. Creating a rainbow table for every possible combination of characters would take as long as brute-forcing the hash.

I thought of rainbow tables, but the salt prevents it.

I'm pretty sure even that will be beyond his worry http://www.bbc.com/future/story/2014...the-far-future

The far far future may not be that far if you have all the asic miners in the world creating hash tables for you. Not that they are, but you've got to wonder.

One of the assumptions people are making to illustrate that it's next to impossible to crack a password, is that the hash is seeded with a truely random number.

Usually they aren't. Truely random numbers are extremely difficult to come by, and this is an achilles heel for all algorithms.

Not really.

Hashes aren't seeded, they are salted. Each piece of data will always generate the same hash with the same salt, that's the whole point of hashing. The strength of a hash lies in the non-reversible nature of the algorithm. No entropy or randomness is required.

The reason salts are used is to prevent direct comparison with existing hashes. If I have a list of passwords and their corresponding hash values in a file, and I later come across the password hash "b036d59cb7f7687a68ba8490b8f57387c785f861" and it turns out it's listed in that file, I will instantly know the corresponding password. If salts are used, one would need one list of passwords and hashes for each possible salt value.

A salt is generated when a password is created or changed and a new hash needs to be generated, and that's an event that happens sufficiently rarely that the accuracy of random generators isn't much of an issue.

But when it comes to generating session keys for symmetric encryption, or key pairs for asymmetric encryption, the randomness of the PRNG is a huge issue. This can be a major problem on embedded systems that need to generate keys when booted for the very first time, since there may not be many sources of entropy available at that time.

No - it just makes the table much bigger.

damn ! i can see the rainbows ! (0_0)

Nothing is impossible. Keep changing your passwords and make sure you mix up all the upper and lower letters and symbols when you setup new passwords.

That says it all.

So much bigger as to render the attack implausible, but not impossible.

Exactly. This was the original reason cracking a DES hash was considered "impossible" in the 70s. The rainbow table was something on the order of 8GB. The larger disk sizes were 300MB. Now disk sizes are 3-5 TB.. but the rainbow tables are in the petabyte range (if not exabyte).. thus making them implausable.

Another attack is the parallel search - if you have a million CPUs to throw at the problem... you likely won't need to keep the results except from the single one that succeeded. But more likely is that there would be a hybrid approach - a lot of different rainbow tables to narrow the search down, then a bunch of CPUS to throw at the remainder.

Choosing a Secure Password (good article by Bruce Schneier)

As stated in the articles, there is a delicate balance between a good password and a password you can remember.

I say don't worry too much about entropy. Hackers typically don't use entropy-based methods to crack. They use dictionaries, because people use words as passwords.

The password should NOT be a common word, and should include numbers. It should also be easy to remember or reproduce by the user.

EDIT:
I'm wondering about Schneider's advice here:
Although 90 days is a bit excessive, I think you should change your password once in a while, like every 6 mo - 1 year.

I really dislike the secret questions, it all sounds like a method of rather easily bypassing your password using personal info. You know what I do ? I put in unrelated information into there.

Write passwords on a piece of paper ? Um, no. I'm not doing that. A password safe was a much better idea.

Hello

Use a strong password, never go online with your machine, never install software on your machine that is not known to be safe, and never allow anyone else direct access to your computer. Do those things and you should be good to go, but you never know these days, so no guarantees. For many people, a strong password along with a firewall and perhaps some security software and a bit of common sense in computing is all they use. They then go forward hoping for the best.

Either way, let us know what you end up doing to protect yourself, and how it works out for you.

Choice of a strong password is actually a very difficult thing for a human to do. Humans tend to be predictable in how we use word and digit combinations, which allows password cracking to be very effective, despite the theoretically large entropy space.
I found this to be a very informative article. http://arstechnica.com/security/2013...r-passwords/1/

[edit]My apologies, just realised that this article is linked in the Bruce Schneier article that Beryllos linked in post #26.[/edit]