Hello Sherlog, Saturday, October 19, 2002, 1:25:59 AM, you wrote: S> As a side note, one iteration of the MD5 compression function takes about 300 S> cycles on a Pentium and 500 cycles on a Pentium 4 (but significantly less if S> SIMD instructions are used to to hash 4 blocks at the same time), and an S> optimized brute-force password searcher can be expected to work at S> approximately this rate. More than one million trials per second is the S> ballpark figure your subconscious should serve up if talk comes to S> brute-forcing passwords ... But you can't make the trials yourself. You have to make them via the Notes C API - which both introduces an overhead and, if I recall correctly, also introduces artificial delays if it finds you making many failed requests to unlock an ID file. (Although there may be a way in the API to bypass the artificially generated delays...) S> This means a normal-sized dictionary can be processed in less than a second S> and all variants derived by appending a single letter/digit can be processed S> in less than a minute - if somebody bothers to reverse-engineer the Lotus S> password hash in order to create an optimized implementation. If you reverse-engineer the whole ID file structure and the hash, then yes you could do this. The program that attacks ID files which was kindly suggested to the list uses the Notes C API, so it requires no knowledge of the ID file format or the hash - it simply keeps asking Notes to unlock the file with different passwords. The Internet hash cracker seems to do it a similar way. (Why else would they both require the Lotus Notes programs to be in the path?) S> Password hashes that are word-readable anonymously via the Internet are not a S> security hole? LOL Oh, they are a security hole. Go back and read my message. They should never have been readable anonymously - someone has screwed up in securing what is only the most important database in a Domino environment. :-( -- Best regards, Philip mailto:philat_private
This archive was generated by hypermail 2b30 : Mon Oct 21 2002 - 08:23:43 PDT