Subject: RE: The Notes password is not stored in the ID file
Thank you for taking the time to explain this.
If I understand all you are saying then it works basically the way I thought, except the notes client is not generating and comparing a hash of the password but rather generating the encryption key itself based off of the text you enter in the password prompt; and either it works to unlock the id or it does not. Same basic idea, but technically different things.
And, if I understand you correctly, the encryption key is a hashed value itself.
All that said, what in the world is stored in the httppassword field? It has got to be a hashed password right? Even the function posted at the top of this thread is like “@hashpassword”
Subject: Did you really mean to ask, “What in the world is stored in the PasswordDigest field?”
Or were you just curious about the encryption scheme(s) used to hash the httppassword? I know I am, and I wonder if the salted version of the encryption used for this field is the same as the encryption used on PasswordDigest.
Subject: RE: Did you really mean to ask, “What in the world is stored in the PasswordDigest field?”
You were correct in that I am curious to understand how the password is hashed and whether or not it was really even a hashed password in that field (httppassword). For all I know now, it is actually a hashed encryption key in that field (which I guess effectively becomes a hashed password) rather than just a hash value of the password itself - even though you would not be encrypting anything with that key. The key itself, would be cryptic, of course. I can’t imagine why you would do something that way, but ultimately, it would work - I think. I guess I ask because he said before that the password was also not stored in the person doc.Of course that may go back to the original argument of the hashed password not being the password itself.
Does that make any sense?
As for the password digest field, isn’t that what keeps up with the recent passwords?
Subject: Well, I was hoping Dave might hit this one, but…
All I know is that the two fields contain the same sort of thing: A hash of a password; just , obviously, two different ones. I just don’t know if they use the same hashing algorithm. (Given, of course, that we’re assuming that we’re talking about the salted hash scheme in the case of the httppassword, since you have a choice of salted and unslated there.)
Subject: RE: Did you really mean to ask, “What in the world is stored in the PasswordDigest field?”
Sorry for the delay – I’ve been dealing with electrical problems that started during the long weekend for the past couple of days.
With regards to the http password: Unfortunately, it’s hard to be clever when you need to interoperate with protocols that hand you the plaintext password, and aren’t even capable of something clever like OTP or S/KEY. Most username/password authentication mechanisms share the common problem that even if a salted hash is stored on the server instead of a plaintext password, the client still sends the plaintext of the password over to the server… and so you had better not use the same password on multiple web servers, because owners of sites of dubious nature can swipe passwords there and try them against financial web sites. There’s not much that can be done when the protocol involves the client handing your server a plaintext password – salt it, hash it, and store it, and hope that users are actually writing down lots of different passwords on sticky-notes in their offices instead of re-using a single password.
Notes has the advantage of using public key cryptography and a well-established hierarchical PKI with a solid naming convention for authentication. The private key never leaves the client, and sniffing the wire doesn’t expose anything that would be useful to an attacker. In theory, someone could gain a similar level of security by using client certificate authentication in SSL, but the PKI just isn’t in place for that, and even if it was, the lack of standards in naming and identity verification by major CAs would make it nearly impossible to be certain that any given certificate was actually issued to the entity whose name is in the X.509 certificate.
However, since Notes authentication was designed with security in mind and doesn’t require sending a plaintext password to the server, we don’t – not even for server-based password checking. Nor do we send over a hash of the password, or a salted hash of the password, or so on. That’s right, the PasswordDigest field does not contain a hash of the Notes password.
I’ll bet you weren’t expecting that answer.
I’ll have to see if I can find a public writeup of password checking anywhere. I may believe that server-based password checking is the wrong solution for most of the problems to which it is applied, but it is definitely a fascinating and ingenious bit of cryptography.
Subject: RE: The Notes password is not stored in the ID file
Dave, this is quite interesting. So there’s no hash of the password stored in the ID file either? I’d always sort of assumed there was.
How, then, does Notes verify the authenticity of a password? When I put a password in, at some point, Notes has the plaintext of my password. What does it do with that plaintext to determine access to the file? There’s obviously some deterministic sequence.
Also, how does this relate to the password hash stored in the person doc? Again, my assumption has been that these are hashes of the plaintext, but your description is causing me to think that you’d never be so foolish as to do this.
This is actually a matter of serious importance for me. I’m working on a project right now that would track medical records throughout Africa, and the security of ID (and local encrypted NSFs) is of paramount importance. Read about some of it here: http://www.openntf.org/nathan/escape.nsf/d6plinks/NTFN-698B3H
If you’d like to contact me directly, I can be reached at nathan@openntf.org. I’d really appreciate discussing these points with you, as we have some very serious systems auditing requirements from both the SA gov’t and USAID.
Subject: RE: The Notes password is not stored in the ID file
That project sounds fascinating!
Which “password hash stored in the person doc” are you referring to? The “password digest” used by server-based password checking, or the “Internet password” used by http/pop3/imap/etc?
Subject: RE: The Notes password is not stored in the ID file
I was referring to the password digest, and don’t fear – I’m following that discussion closely.
I’ve been quite clear for a long time on how the Internet password stuff works. Actually, I had an exchange with Charlie not long before his departure about the password verification methods in ND6 and some approaches that a colleague of mine and I were trying to use to attack via that route. (That was my first encounter with the increasing delayed response mechanism that’s built in.)
I’ve been making a point of trying to understand Notes security since v2. I remember a conversation I had with Charlie in '95 after his LS presentation. “Charlie, shouldn’t I be able to access an ID file if I have the original certificate used to create the ID in the first place? Wouldn’t that just be a matter of having a copy of the private key for the ID that’s encrypted with the private key of the certificate?” “Well, you couldn’t do it exactly like that, but you could…” and then he got all excited and ran off to talk to one of the other Iris security guys. 'Twas an interesting experience.
You should NOT be entering a default password for the blanks. Instead, you should create a button to send user via email that will prompt them to create their own password based on rules you have set and have the agent populate the field for them.
There are sample applications in the Sandbox that will help you in this direction.
You don’t really want to use LS to do this anwyay. You should use formula.
Create an agent and use formula. Set the agent to run on selected docs. Create a view or whatever to get all the docs you want to set, or manually pick them out of another view - whatever - just get them selected.
Then run the agent against them. Here is the code:
Subject: Small issue::Script to enter Internet Passwords
Thx Guys !!! for ur reply… But what if i already have http password entered for some users which i dont want to change. The code/agent should be capable of identifying only those documents whose Internet Password field is blank.Reg
