Hacker Jeff Moss Sworn Into Homeland Security Advisory Council

Wolfgang Kandek writes "Hacker Jeff Moss, founder of computer security conferences DEFCON and Black Hat, has been sworn in as one of the new members of the Homeland Security Advisory Council (HSAC) of the DHS. Moss, who goes by the handle 'the Dark Tangent' says he was surprised to be asked to join the council and that he was nominated to bring an 'outside perspective' to its meetings. He said, 'I know there is a new-found emphasis on cybersecurity, and they're looking to diversify the members and to have alternative viewpoints. I think they needed a skeptical outsider's view because that has been missing.'"

Comments

Re:Maybe Jeff can explain this

[osu-neko]

I see a number of people have answered, but none have giving a simple and straightforward explanation to what's wrong with your question.

Simply put: Unix does not store your password. If you've been told Unix stores your password encrypted somewhere, someone was glossing over the details to the point of making false statements. People can't reverse the process of decrypting your password because your password isn't stored there to begin with.

If you want to know what is actually stored, follow the previous advice about looking up hashing algorithms. Quick a dirty answer: when you first type in your password, a hashing algorithm is run over it and a hash code is produced, which is stored. When it prompts anyone for your password, it doesn't know the correct answer, but whatever answer anyone gives, it runs through the same hashing algorithm and sees if it produces the same result. The odds of two different strings producing the same hash result vary with the algorithm but it can be something like 1 in 2^160.

But the short answer is, your password cannot be decrypted because it wasn't encrypted and stored to begin with. There's nothing to decrypt.

Re:Maybe Jeff can explain this

[vux984]

If a known algorithm produces the encrypted password, why can't that algorithm be "reversed" to produce the original password in the first place?

It has been. But it doesn't really do you any good. The actual password is lost. The reverse of a hash produces infinite solutions. (In the same way the reverse of modulus division produces infinite solutions).

But those solutions are all 'collisions' and they could all be used interchangeably with the original password. So getting any solution is almost as good as getting the original.

Even in open source systems, encrypted passwords are not easy to crack. Why?

Because pretty much all modern encryption is based on the idea that its VERY easy to multiply two stupidly large prime numbers to find an even stupidly larger number. Multiple two 1000 bit prime number numbers and get a 2000 bit non-prime as a result.

But it takes years upon years of processor time to take that stupidly larger number, and factor it back into the original stupidly large primes.

Could a slashdotter post some "simple to understand code" that produces output I cannot reverse engineer?

z = primex * primey;

suppose z = 377, how do you find the factors: 13 and 29?
Now, for encryption, z is thousands of digits instead of 3.

Algorithms that solve this exist, they just won't finish running until after you've died of old age.

Re:Maybe Jeff can explain this

[Bob9113]

Could a slashdotter post some "simple to understand code" that produces output I cannot reverse engineer?

While I *love* the first respondent's answer, and giggled like an idiot when I read it, perhaps this will be more a more useful example for understanding how it works.

The modulus operator in arithmetic returns the remainder after integer division. It is commonly noted "x % y", "x mod y", "mod( x, y )", or similar.

So:
3 mod 2 = 1
4 mod 3 = 1
4 mod 2 = 0
5 mod 2 = 1
5 mod 3 = 2
5 mod 4 = 1 ...

Now, suppose a password structure "x:y" -- you are required to enter your password as two digits, separated by a colon (not normal, but just suppose).

You could enter, as your password, "4:3", and the system could store as your password hash "1" -- the result of "4 mod 3". Then, when you attempt to log in next time, if you submit "4:3", the system would take the modulus and check the result, "1", against its internal table of password hashes and allow you in.

Now, suppose you get the table of hashes, and see:
joeSmith: 1

joeSmith has the password hash "1". Is his actual password "3:2", "4:3", "5:2", or "5:4"? Since the modulus of all those pairs is "1", the correct answer cannot be determined from the output alone. Modulus is what is called a "non-reversible function." The output of the modulus function contains less information than the input, so it cannot be reversed.

In this example it is trivial, however, to generate another password combination that results in the same hash. For example, "6:5" also equates to the hash "1". This is called a collision between "6:5" and "4:3". The attacker does not have to know joeSmith's actual password, as long as he can supply input that results in the correct hash. That leads to the next step in identity verification systems: ensuring that it is not possible for a reasonably funded attacker to forge a document which collides with the actual document (or password in this case, which is a special kind of document).

That is a much harder topic.

Re:Good luck with that, Jeff

[The Dark Tangent]

Thanks for the encouragement! I serve at the pleasure of the Secretary, and will do my best to give the HSAC and her the information and opinions I think are necessary to make informed and non-lame decisions. The rest will be up to the powers that be. Like someone said in another post, I have no horse in this race. I'll try to make a positive change and if I feel I can't because I am the wrong person for the job then I'll step aside for someone who can.