Hacker Jeff Moss Sworn Into Homeland Security Advisory Council 139
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.'"
Re:Maybe Jeff can explain this (Score:3, Informative)
Look up one-way hashing algorithm. The hash (encrypted password) does not contain all the info of the clear password, so you can't get the password out of the hash. It's a feature.
Or maybe that's not your question?
Re:Maybe Jeff can explain this (Score:1, Informative)
Re:Maybe Jeff can explain this (Score:4, Informative)
Why? Discrete mathematics, my friend, and in particular, modular arithmetic. (You know, from fourth grade, when you'd do 11 / 3 and get "3 remainder 2" - the 'modulo' operation just gives you the 2.) Now suppose you have an algorithm:
a = x % 731
b = x % 129
Now take a number: say, x = 10,000. Easy to compute: a = 497. b = 67. Very easy to calculate. But, working backwards from a and b alone, can you determine x? Suppose a = 616 and b = 100; can you tell me what my number is? It's not quite that easy! You'll need to do a lot more math. Not too much, in this case, as this is a ridiculously simple code and the numbers are small, but a lot more than a simple integer-division-and-remainder operation.
That's not an encrypted message. (Public-key cryptography is related but different.) That's a simple one-way cryptographic hash: a secret number (your password) goes in, and a mysterious hash-value (a and b) comes out, and there's no easy way to map it back. But if you give me the password, it's easy to check that it's right. That hash value is what's in your shadow password file. Except it uses MD5 or SHA or whatever-the-latest-hotness-is.
Now, granted, there's few enough passwords that you can check them all, given enough time. (You might even precompute them all, which is why you add a little random 'salt' to each password that makes them all different. In the example above, the 'salt' could be 'add 12345 to X before hashing it'. You can store the salt next to the encrypted password - you'll need it to check the password. It only protects you from the guy who calculated all the passwords adding +12344 each time - his "rainbow table" of passwords and hashes is now useless.). That's why the shadow-password file isn't usually broadcasted to the world. You try to keep it reasonably secret: not world-readable, certainly not exposed to the Internet. But it's a whole lot better than nothing.
Re:Maybe Jeff can explain this (Score:5, Informative)
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 (Score:3, Informative)
http://en.wikipedia.org/wiki/One-way_function [wikipedia.org]
Re:Maybe Jeff can explain this (Score:5, Informative)
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 (Score:5, Informative)
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:More change for the US (Score:1, Informative)
Another misguided person who thinks state control is socialism. If I redefine a fire in my house as a "house warming party" it still won't save my house. By the same token, defining everything you don't like as "socialism" won't help you understand either what socialism is, or what the defining features of fascism are. And if you cannot recognize it, you are powerless to do anything about it.
Re:Not quite (Score:3, Informative)
And that's why we get agencies that think they've secured their networks when they haven't (the more redtape exists, the more loopholes there are).
The name of the House Committee escapes me, but they do yearly reports on computer security and gov't agencies regularly get Ds (up from their previous Fs).
http://csrc.nist.gov/groups/SMA/fisma/index.html [nist.gov] demonstrate its compliance with the security requirements as opposed to how well the requirements are actually implemented.
Re:Good luck with that, Jeff (Score:5, Informative)
Grats DT (Score:4, Informative)