I want to put a standard internet password for my 1500 users. I dont know Lotus Script. Can somebody gimme the script for the same?Please also note that i dont want to change the Internet passwords for the users who already have Internet passwords entered…
Regards
Subject: Script to enter Internet Passwords
i think it is not possible. but you can force all users to change the internet password on next login. password is a part of notes id file.
Subject: RE: Script to enter Internet Passwords
Actually, the Internet password is not part of the Notes ID file, nor is it stored in the Notes ID file. If you feel like being horribly insecure, you can set “synchronize Internet password with Notes password”, but even the Notes password isn’t actually stored in the ID file.
Subject: RE: Script to enter Internet Passwords
Say again??? You are correct in all you said about the http password,but the notes password (or the notes id password)is stored in the ID. It can also be cached in the person doc for tighter security purposes, but it is stored in the id itself.
Subject: RE: Script to enter Internet Passwords
No, it’s not. The password is not stored anywhere. A salted hash of the password is used as an encryption key for some of the id file’s contents, and a hash may be stored in the password digest field on the Person document. There is no way to determine the password from either the file or the Person document.
Subject: RE: Script to enter Internet Passwords
My friend, you are very wrong. It may be hashed, but it is still the password (just in hashed form). I have a brute force cracker that will most certainly determine the password right out of an ID file - assuming it is not too complicated.
Subject: RE: Script to enter Internet Passwords
How is storing a hash the same as storing a password? You cannot work backwards from the hash to the password. A brute-force approach doesn’t “get the password from the id” – it tries all possible combinations until it finds one that produces the same hash. That’s where the “assuming it’s not too complicated” part comes in – and where the password quality setting does its job.
Subject: RE: Script to enter Internet Passwords
Stan, effectively, it is the password as the password is obatinable from the id itself. You are trying to be overly technical here. I never said that it is just stored in there as is in plain text.
Subject: RE: Script to enter Internet Passwords
Frankly, there is a HUGE difference – it is not “overly technical” in the least. By the way, brute-force would also work EXACTLY THE SAME WAY if the hash was never stored, and was used as an encryption key only. In other words, you are never extracting the password – you are guessing until you accidentally find a string that unlocks the ID file.
Subject: RE: Script to enter Internet Passwords
Oh for goodness sakes. Notes 101 teaches you that the password is stored in the notes id file. You must have missed that class. So it is stored in a hased form. So what? I would not expect them to put it in as is in clear text. And to your last statement, that is irrelevant because it is stored, which was my whole point in the first place. Stick to the facts at hand, please. I only brought up the brute force crack because YOU DID SAY there was no way to get the password out, and you were wrong in that statement.
Your whole argument seems to imply that if I encrypt my one of my ms word files on my hard drive with pgp that I can no longer say that my word file is on my hard drive. Oh it’s there; it’s just encrypted.
Subject: RE: Script to enter Internet Passwords
“Your whole argument seems to imply that if I encrypt my one of my ms word files on my hard drive with pgp that I can no longer say that my word file is on my hard drive. Oh it’s there; it’s just encrypted.”
Isn’t PGP a reversible encryption scheme? The hash of the Notes password stored in the ID file is not a reversible scheme. Not by any means. To be honest, I’ve never figured out what purpose it serves in there.
“I only brought up the brute force crack because YOU DID SAY there was no way to get the password out, and you were wrong in that statement.”
As Stan has already pointed out, the brute force cracker does not “get the password out” of the file; it simply guesses password after password until one of them works. (That is, after all, the definition of a brute force cracker.)
“Notes 101 teaches you that the password is stored in the notes id file.”
Yep, we sure do tell end users that the password is stored in the ID file, even though it’s not true – and we hope, usually futilely, that they remember that untruth. If they believe that, then they’ll be less likely to call the helpdesk and initiate an ID file recovery process when they have multiple copies of their ID file with different passwords – assuming they can keep the passwords straight, of course. When I teach Notes admins in Admin 101 about the ID file, I tell them that the password isn’t stored in it, but they should tell their users that it is.
I think the distinction here (the one that survives simple semantical manipulations) is that the hash stored in the ID file cannot be used to arrive at the actual password, and given that fact, it’s reasonable to say that the password itself isn’t in there.
Subject: RE: Script to enter Internet Passwords
Look Bruce, I think the key word you missed here was in another post. I was saying that it was EFFECTIVELY, EFFECTIVELY, EFFECTIVELY in there because the hash was there and based upon that, the password could be determined through passing strings of text through the same hashing algorithm until a match was found. I understand it (a hash) is not reversible. And I understand the difference between encryption and hashing.
In any event, it does not matter because now I am reading that the hash is not even in there which makes my whole argument, and yours, a couple of futile stances (at least argument on the hash actually being the password - which I do understand your viewpoint). It would appear, however, that the stance of the password not being in there was in fact, correct all the time and I will therefore concede that I was wrong - especially since the hash is not even in there.
Thanks.
Subject: The Notes password is not stored in the ID file
I hate to have to disagree with you on this one, but the password is very definitively not stored in the ID file. The hashed password is not stored in the ID file, either. Most ID files have passwords associated with them, and some people might confuse “associated” with “stored in”, but confusion is not truth.
The way that someone brute-force attacks an ID file involves generating encryption keys derived from likely passwords, and then attempting to decrypt the ID file with those encryption keys. There are substantial work-factor differences between this style of password-guessing attack and simply comparing pre-generated hashes stored on a DVD with hashes found in a directory or a file, and if the ID file’s password has a reasonably high quality, then the brute-force attempt is unlikely to succeed in a reasonable period of time.
In fact, since the space of possible passwords is substantially larger than the space of possible 128-bit hash values, one could not prove conclusively that one had, in fact, guessed the correct password for the ID file, merely that they stumbled across a collision in the hash function with the correct password. Claiming that the hash of the password is equal to an encrypted copy of the password would be tantamount to saying that you don’t need to send waste bandwidth by sending signed messages to people – you can just send the signature, and they’ll be able to magically extract the 3 megabyte message from the 128-160 bit long hash.
I presented the “Crypto 001” talk (“This is not Charlie’s security session”, actually – Crypto 001 was the first section of the talk) at Lotusphere this year, and among other points covered basic cryptography, key strength/entropy, and ID File encryption. At no point in time did I ever lie to the audience and tell them that the password, or a hash of the password, was stored in the ID file as part of the way that the ID file is encrypted. It isn’t. I would know. I have the source code. 
David Kern
Resident Paranoid
Notes/Domino Security Group
…
Subject: RE: The Notes password is not stored in the ID file
Thank God. I learned this fact a long time ago, but so many posts in this forum from so many people who know Notes very well cite the existence of this hash that I had decided the original knowledge I had was wrong. Thanks for authoritatively sewing this one up.
Subject: RE: The Notes password is not stored in the ID file
I would like to second the previous question by Nathan
"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.
"
My assumption was that the notes client was passing the password through the same hashing algorithm and when it matched, it decrypted the id file.
And, I don’t understand this statment:
"In fact, since the space of possible passwords is substantially larger than the space of possible 128-bit hash values, one could not prove conclusively that one had, in fact, guessed the correct password for the ID file, merely that they stumbled across a collision in the hash function with the correct password. "
It sounds as if you are sayin you could in theory pass an entirely different string of text and come up with the same hash. Is that correct? And if so, I still don’t understand the whole point because you said the hash was not in there - yet now you are talking about hash again.
If you would take a moment, I would like to understand this better.
Subject: RE: The Notes password is not stored in the ID file
I’m responding to this post first because the response is easier. I’ll get to Nathan’s once I’ve had time to follow that link.
My assumption was that the notes client was passing the password through the same hashing algorithm and when it matched, it decrypted the id file.
Most people tend to have assumptions regarding security that are based on typical password-based authentication protocols. With these, the client will send the password or a hash of the password to the server, and the server will then compare against a stored value and accept or reject the authentication attempt. However, when encrypting a credential store, there is very little cause to store and compare, since you can use the decryption process itself to confirm that the correct key was used.
Notes will derive a key from the Notes password, and then use that key to decrypt the encrypted portions of the ID file. If the ID file decrypts successfully, then we know that the right key was used. How do we know that the decryption succeeded? Well, the most common technique involves the padding.
Many ciphers can only be used on data that is a multiple of their “block size” in length. For example, RC2, DES, and 3DES all have block sizes of 8 bytes, and AES is defined to use a block size of 16 bytes. However, most data doesn’t conveniently fall upon onto these boundaries – can you imagine how annoying it would be to send encrypted email if you program refused to send the message until it was the correct length? Therefore, the end of data that is being encrypted is typically padded out to the next block boundary – and an entire padding block is used if the end of the plaintext fell onto a block boundary. In the padding scheme defined in PKCS#5, each byte in the padding block is filled with the number of pad bytes used. With this padding scheme, if you decrypt a message, and the last byte is “0x05”, and the previous four bytes are also “0x05”, then you have a high degree of probability that the decryption succeeded - and you also know how much of the message was padding and can therefore be discarded. Notes doesn’t use PKCS#5 – we predate the PKCS series of specifications by quite a few years – but the same concept applies to the ID file. We decrypt the ID file using a key derived from the password, and if the padding matches and our internal checksums are correct, then we know that the correct password was entered.
I hope that was reasonably coherent.
"In fact, since the space of possible passwords is substantially larger than the space of possible 128-bit hash values, one could not prove conclusively that one had, in fact, guessed the correct password for the ID file, merely that they stumbled across a collision in the hash function with the correct password. "
It sounds as if you are sayin you could in theory pass an entirely different string of text and come up with the same hash. Is that correct? And if so, I still don’t understand the whole point because you said the hash was not in there - yet now you are talking about hash again.
The function that is used to derive the key from the password involves hashing. The first step involves hashing what could be a 8*63=504-bit long password down to a 128-bit hash. Since there are more potential passwords than there are resulting hash values, more than one password could map to any given hash value. These are what are known as collisions. Those identical hashes would then result in the same decryption key for the ID file. However, cryptographers worry about many threats that are completely impractical in the real world, and this is one of those… at least as it relates to password-derived keys.
dave
Subject: RE: The Notes password is not stored in the ID file
But then the password is actually stored in the ID file, not as plain text, not as a encrypted string, but as a result of an encrypted portion of the ID file.
Subject: RE: The Notes password is not stored in the ID file
No. You can attempt to guess the password by performing trial decryptions on the ID file, but this does not imply or require the presence of the password or any information derived from the password in the ID file.
Subject: RE: The Notes password is not stored in the ID file
Dave,
Thanks for the great feedback. This is, indeed, the major part of what I was looking for.
If memory serves, the name associated with the ID and the signed public key of the ID are not encrypted within the file either, correct? It’s only the private key (and presumably any embedded shared keys) that are encrypted in the ID. I suppose the truly authoritative check is whether the decrypted private key is a match for the non-encrypted public key, no?
I look forward to further discussion on this matter, particularly as it relates to the digests stored in the person doc. Are these possibly related to the 128-bit hashes derived from the password?
Subject: RE: The Notes password is not stored in the ID file
Correct, the name and certified public key (Notes certificate) are not confidential information, and so are stored in the clear. The set of confidential information includes the current private keys, any old private keys, all document encryption keys (NEKs), all Internet private keys, the information used for server-based password checking, and some other stuff that doesn’t leap immediately to mind or isn’t terribly visible at the user level.
We could verify that the ID file was decrypted successfully by encrypting a random value with the certified public key and then decrypting it with what appeared to be the private key, but the odds of the padding matching after a failed decryption and the resulting garbage appearing to be well-formatted with accurate checksums is astronomically unlikely.
I’ve addressed the http password and the digest used by password checking in another response on another branch of this thread.
dave