25 Apr
2007
25 Apr
'07
1:04 p.m.
It's not
reversible because a hash algorithm is used. [...]
Yes, but it is possible, either
by brute force or clever programming,
to write a job that will produce a string that will hash to the same
hashcode as the target password. With a 16bit hashcode, a set of 65536 strings can be
made and
sequenced that will work for any 16 bit hashcode with that algorithm.
Yes and no. This is true provided the algorithm is not salted, or you
consider each salt as a separate algorithm - or as part of the hashcode
size. Otherwise, your dictionary size must be multipled by the number
of possible salts - that's what salts are *for*.
It will most likely be a nonsense string of
characters, rather than
the name of the user's canary, but it will work.
Not necessarily; for example, if it contains NL or NUL characters, it
will not work as a Unix password, even if it does produce the correct
hash when shoved through the algorithm.
In fact, if you were to start filling in the table
with a
dictionary/namelist approach, many of the "passwords" will actually
match!
This has been done. It's why password hashes are salted - to multiply
the necessary dictinoary size by the number of possible salts.
That is why the hashcode algorithm being used should
be kept secret,
Security through obscurity? Doesn't work. Certainly not in a case
like this, where implementations of the algorithm are, perforce,
widespread.
and access to the hashcodes for accounts shuld be
limited.
That helps, a little, but it's a belt-and-suspenders measure.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B