Hi guys
Got a Problem in the fact that I believe that an employee at our place has got hold of another persons ID file and he is going into their mail files.
I need to catch him but he’s savvy to the way notes works, and cleans out his local log.nsf every five minutes.
I need to prove that he has gone into another persons mail file. Any ideas?
Subject: Security Problems
Jon,
First, make sure that you are using Password Checking for the user whose ID is compromised. Second, have them change their password to a good one. Now the stolen IDfile is of no use.
HTH,
Bob
Subject: RE: Security Problems
the only downside of this approach (which is good) is that it does bot allow the company to catch the “bad egg”.
Subject: RE: Security Problems
Instead of password checking, have the real user request a new key pair, and turn on public key checking. That way, any new encrypted email messages won’t be decryptable by the stolen ID file.
Subject: RE: Security Problems
then you have the problem of encrypted e-mail files that might not should (love southern expressions) be encrypted. And you still have the issue of proving the unauthorized access is going on.
Subject: might should not?
That’s an expression I’ve never heard before… 
Public key checking will log failed connection attempts, so you could demonstrate that another party was using a copy of the ID with the old keys. Finding out where that party is physically located would take some actual work, though.
Subject: RE: might should not?
P’raps, but the real user still loses anything that was encrypted. That kinda punishes the wrong guy, eh?
Subject: RE: might should not?
Generating a new key pair doesn’t discard the old ones. The old keys are archived in the ID file for access for, for example, old encrypted email messages.
Subject: It’s been a long time since I’ve tested this, but I have never been able to decrypt previously-encrypted stuff after issuing new keys.
Please tell me that it really does work for you.
Subject: Works fine…
Notes has had this capability since the ability to generate new keys for an existing ID file was first introduced, years and years ago. V3?
Keep in mind that if you register a new ID file that just happens to have the same name as an existing ID file, you will lose all of the information in the old ID file, including all of the keys. All operations of this kind (new key pair, move within the organization, rename, etc) must be performed on the existing ID file – just creating a new ID for an existing user is a very bad idea.
Subject: RE: Works fine…
Yes, this capability has been around since R3 – it’s just that it didn’t work for me the one time I tried it years ago in R4, and since R4.5 introduced the less-admin-intensive password checking option, I’ve never needed it since. I know that all the documentation has always said that it works, but documentation is sometimes completely wrong, and functionality is sometimes inconsistent. Hence my question.
But it’s nice to know that I appear to be the only one who couldn’t access data encrypted with the original public key after issuing new keys. I’ll write it off to bad electrons in that computer.
Subject: RE: It’s been a long time since I’ve tested this, but I have never been able to decrypt previously-encrypted stuff after issuing new keys.
This has always worked nicely for me. When you get a new certified key, the ID file retains the old private key information for precisely this purpose.
Subject: Security Problems
First thing is to give the user a new ID and adjust the ACL.
Other thing to do is create a post open event in the mail file to trap where the user is coming from and generate an email with the information (eg. @maildbname which pulls the info from the ini file I believe).
The more pressing concern is how this user not only got the ID file, but the password and this is a systemic weakness that beeds to be addressed by your company.
Subject: Security Problems
If you want to identify a particular machine on the network, you may have to go outside of notes. The post-open event is a good idea - in that it might bring some .ini info back. Obvioulsy changing the password or creating a new ID renders that bad guy’s no good - so you have to keep him live at first.
I might try something like this. In a post save or post close event I would add an additional mailsend to another account. Something like, on save @mailsend. Have it generate an email to a new mail file. Find the time that the mail was sent and locate the entry in the server log. The cross-reference the server log with the transaction log of the server to find out which machine on the network the mail was sent from. Depending on the activity, you may have to get a couple transactions in order to match them conclusively.
Just a thought…
Subject: RE: Security Problems
or watch the server database users view and look at the mail database, track the ip numbers of the connecting machine and match to the user,
or you could search his hard drive for *.id and locate the id
how did he get the password?
of course if he knows the user name and password and it still the same he could be reading it via inotes
Subject: RE: Security Problems
First of all Thanks guys for all the suggestions.
The basic situation is that we (IT Admin bods) keep a copy of Ids locked down on the Network. It obviously wasnt locked down enough. (A seperate dispute with Windows ;o) He’s also IT and thus has a very good working knowledge of Notes as hes one of our Notes and VB Programmers.
I know who the culprit is, but I need proof.
Im gonna get to work on some of the ideas that you guys said about, Ill let you all know.
Thanks again so much!
Jon
Subject: Note that this is a poster child issue for storing ID file backups in a database instead of on a file server.