Cracking the code?

[mis at seiden.com]

the hex value stored is perhaps a hash, or even better, a salted hash,
or even better, a keyed salted hash which is then hex-encoded.  any
discussion of unix password cracking will describe the first two.
(i think even the original doug mcilroy paper)

all are vulnerable to dictionary and brute force attacks.
an unsalted hash also reveals what two users have the same 
password as their hashes are the same.

yes, you could also precompute hash values instead of using attacks
which enumerate the values and their hashes. 

if the hash is sent to a counterparty to authenticate the user (to make
unnecessary  their typing a password) it has the same protective power
as a plaintext password.   if you have the hash, you can pretend to be 
the user in any situation which accepts the hash as an authenticator.

the only value of such a hash is to obscure the password and to make less
likely that someone with the hash can take advantage of the user using the
same plaintext password in other circumstances.  

this is the main reason why static authenticators such as passwords
should generally not be reused, or, for that matter, used at all for
high value asset protection.



On Sat, Mar 03, 2007 at 04:09:36AM -0800, Allen wrote:
> Hi gang,
> 
> On recent consulting gig, I came across what I think is a 
> potential vulnerability and wanted to see how crazy my thinking is.
> 
> Without mentioning the exact place or piece of software because 
> of NDAs, here is the basic scenario.
> 
> The tool stores the hex version of the remote access password in 
> a field that is visible to the end user. The default setting of 
> the software is that if you enter ASCII into the field, it will 
> calculate the hex version and display it. At this site the sys 
> admins have decided that this is not a user settable field so 
> once set the user can not change it except with the help of an 
> admin. There is also no policy in place to require periodic 
> password changes.
> 
> Also every user in the entire enterprise has this field visible 
> in their LDAP address information that anyone in the company can 
> access at any time. The address info also contains the user name 
> for logging onto the network. The password for remote access 
> appears to be the same as the password for logging onto the 
> machine even when it it not connected to the domain.
> 
> Next, trial versions of the software are available that still 
> have the default setting where the user can enter any password 
> and the hex value will be shown. As to the password algorithm 
> itself, I don't know what it is. I don't know if it uses an IV 
> that changes for every password that is entered, but that would 
> be easy to check with the trial version. What research I've done 
> says that it is derived from AES128 and it is a fixed field 
> length. There is more than a bit of security by obscurity at play 
> here.
> 
> So it seems to me this is vulnerable to a know text attack: i.e., 
> enter "known password 1" get back "hex value 1", etc. By hand it 
> would take a while to build a list of equivalences, but I assume 
> that a clever perl hacker, which I'm not, could code a widget 
> that would automate this, taking a common dictionary such as from 
> Cain & Abel, John the Ripper or some such, and fairly quickly 
> build a list of password/hex pairs. With this list in hand an 
> insider bent on industrial espionage could find the weak 
> passwords of sys admins and logon as them and do whatever 
> nefarious deeds they wish.
> 
> My questions are: A) is this as vulnerable as it seems at first 
> blush? B) how many password/hex pairs would be needed to deduce 
> the underlying algorithm?, C) If one could deduce the algorithm, 
> could the attack be generalized so that it could be used against 
> other enterprises that use the same software? (It is very(!) 
> widely deployed), and D) am I missing something in my thinking?
> 
> Thanks,
> 
> Allen
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com