Re[2]: UserID and hashed password for Lotus Domino

[Philip Storry <phil () philipstorry net>]

Hello Casper,

(I cc'd the reply to the vuln-dev list, in case it's of interest to
others. I hope you don't mind me doing this.)

Saturday, October 19, 2002, 5:44:02 PM, you wrote:

g> 5.0.9a

5.0.9a is recent enough to have offered to close most of those gaps -
unless they upgraded from an R4.6 server...

> > 2. The ID file is on the person document because a lazy administrator
> > left it there.

g> guess so, and dont know for what strange reason, since other users didnt
g> have the ID available (I couldnt check all of 2000 users anyway).

Yeah, checking all of them would be a bit much. As I said, it may be a
user that's not yet had their client set up. It's regarded in the
Domino community as a convenient method which is only slightly
unsecure. The ID file will get you nowhere without a password... ;-)

Personally, I prefer not to put ID files in the Domino Directory at
all, but there are occasions when I've had no choice.

> > 3. The password digest is NOT necessarily the same as the password in
> > the ID file. The most recent version of Domino/Notes (R6) does, I
> > believe, offer the option of changing the internet password (The
> > digest you describe) when the ID password is changed - but obviously
> > the ID file's password cannot be changed from the internet browser
> > end, as the browser has no knowledge of what an ID file is.

g> The password in the ID file, is the password to login into Domino right?
g> One user had the password digest shown in the Administration section of his
g> document, but not the Internet (HTTP) password.

The password digest in the Administration section is a digest of the
password in the ID file. The ID file can only be used by a Notes
client, or via the Lotus DOLS (Domino Offline Services) software.
Although DOLS does "tunnel" through HTTP, it's not actually a HTTP
protocol and therefore it's safe to say that the ID file is useless to
a browser. Therefore that digest in the Administration section is also
useless to a browser.

g> Since this user is my dad (he works at this company) I had the chance to ask
g> him let me see his internet password digest... well, it's different from the
g> latter digest, even if he told me the password is the same.
g> So ... does that mean that domino 5.0.9a uses "salted" hashes?
g> or does that mean that domino 5.0.9a uses two *different* algorithms for ID
g> password and HTTP password?

The hashing method for the ID file is, I'd imagine, a hash algorithm
from the RSA BSAFE libraries. That is to say that it's actually
something that's compiled code in the executable.

The hashing of the Internet Password is actually done via a formula
language statement (@Password), which may or may not use the same
algorithm. Formula language is a compiled "macro" system, so I can't
say whether or not it uses the same hashing algorithm. I do know that
the algorithm was changed in R4.6 (well, a second algorithm was
added) - that seems to indicate to me that it is a different
algorithm entirely.

However, it may well use exactly the same algorithm, but it might be
presenting the results differently. I note that the password changes
from the hash value it computes for display to a different hash value
for storage.

I'm afraid I can't say definitively whether or not different
algorithms are used... But the evidence seems to support that they
are.

> > Lotus is extremely coy about the ID file format. However, I do know
> > that they use the RSA BSAFE libraries, and that the password can be
> > checked by the server to ensure that the ID file and a stored hash at
> > the server are the same. This suggests to me that the password is
> > stored as a hash in the file, making it difficult - if not practically
> > impossible - to extract the original password plaintext from.

g> I wonder, what need is in storing the password inside the ID file?
g> Why not just keeping it in the server?
g> (uhmm maybe is this for when you log in the notes client and you're not
g> connected to the server? dont know much about the domino world, sorry)

The Notes client will not even connect to a server unless the user can
provide the correct password for the ID file. Doing it this way cuts
down on network traffic, and shows the importance of the ID file.

The password in the ID file is used to "unlock", or allow access to,
your secret key. Notes/Domino uses public key cryptography, and this
is an identical operation to unlocking a PGP keyring really. The very
moment you unlock the ID file, you have established your identity.
This is true whether or not you are connecting to the server - Lotus
Notes is designed for remote work as well, and you still need to
authenticate then - otherwise Notes would not know who to say had last
changed a document etc...

As I stated before though, the ID file is only used by the Notes
client. So it's of no use to an attacker with just an internet
browser.

g> Do you mean that the hashing of the Internet password is *weaker* than the
g> hashing of the ID password ?

As I said earlier, I don't know for sure. But remember that the Notes
client takes work away from the Domino server, because it handles all
the unlocking of ID files etc.
A Domino server has to hash passwords that are presented to it, and
then compare them with the stored hashed version.

Given that an internet browser is inherently weaker in security than
the Notes client, I don't see why Lotus should go to great levels to
try and put the same levels of security into browsers. It would
probably require proprietary plugins and so forth, and quite frankly
it wouldn't be worth it. Surely it's much simpler to make the http
server/browser connection as secure as the standards allow, and then
leave it at that?

I have no proof that the http password hash is weaker, but I just
can't see a reason to make it stronger. ;-)

g> Right now I cannot stay with my home computer crunching passwords because it
g> takes really long and 100% cpu, and I dont even know if that is possible (as
g> you said).

Well, I know exactly how you feel. Personally, I think that computing
the original values that the hashes represent is a dead end. Remember
that nobody should have access to these values in the first place - so
once the Domino Directory is secured, it won't matter if they take
five minutes or five years to "crack".

g> But I can make a try. I can ask my dad to give me his userID file, then
g> write his password into the dictionary file, and then try the attack... just
g> to see if that tool other people suggested me really works.

I've not yet tested it myself. Remember that the passwords will be
case sensitive. That's why I responded to that email saying you're
going to need a huge dictionary file. :-)

R5 introduces the concept of password quality to ID files, which makes
dictionary based attacks a bit useless as you're suddenly required to
either pick a VERY long word or to add numbers and punctuation to
short passwords. (The exact "quality" is picked by the administrator,
of course.)

Because of this, I feel that dictionary attacks are a bit useless. If
the program could do a dictionary attack followed by a brute-force
attack, then it might be of more use but it would take a while to have
any effect.

g> Many thanks about this.
g> I do know these are security holes just because of sloppy administration,
g> not because of Domino, which I consider a very very secure platform.
g> Thanks alot :)

Domino/Notes is a secure platform, but sadly the web side of it is
misunderstood. It suffers from all the various insecurities that web
services have, because a web browser is a dumb client and kows less
about security than I do about cross-stitching. But too many people
assume that it naturally has the same security that the Domino/Notes
client combination has.

It's a pity, really - I can't help but feel that the humble web
browser has tarnished the good name of many security products in this
way. ;-)

-- 
Best regards,
 Philip                            mailto:phil () philipstorry net