Hello, here's my ¤0.02... note that I would not call myself a crypto expert either.
On Thu, Aug 12, 2004 at 11:54:14AM +0200, Marcel Weber wrote: > My solution is a mod_perl module, that catches every request before the > authentication module and supplies the credentials automatically. This > works with ANY apache authentication modules using basic authentication. This strikes me as a weird solution. What's wrong with setting the cookie lifetime higher, so that people only need to log in e.g. once a day? Hmm, presumably the web application is closed-source or un-hackable due to other reasons... > The cookie has a limited lifetime, is bound to the client's IP address > and is AES256 encrypted, with a server side stored encryption key. If I understand this correctly, you have one central server-side AES key which never changes. From a security design POV, this is bad - a malicious user might be able to turn your Apache module into an oracle; he can supply a huge number of fake user/password strings and analyse the encrypted cookie's contents, with an intent of cracking the central key. I see no immediate way for him to succeed in this, or indeed a way to make use of the master key, but it does not "feel" good. An alternative approach to the whole problem could be to use a server-side database of user/password data. The cookie could contain just a random string of bits to reference the right database entry. > I discovered, that if I changed this encryption key, the module would not > return, as it could not decypher the credentials. Furthermore someone > could send an invalid cookie which would cause some DoS attack. So I > added a checksum over the encrypted credentials and the key itself. This > checksum has the form of an md5 hex checksum and is checked before the > decyphering of the credentials takes place. Again, this feels wrong if I think of abuse of the server as an oracle. Maybe consider encrypting the checksum with the rest of the data, i.e. $c = encrypt( $s . md5($s) ) > I'm no cryptographic expert, so I'm asking this: Using AES256 in CBC > mode, if I have a key $k and a string $s representing the credentials, > that's encrypted with this key and if I calculate the checksum following > this method > > $c = md5_hex( $s.$k ); > > Does $c compromise the security of the the encrypted credentials, resp. > the key $k? For all practical purposes, this should be fine. For example, there are far easier attacks if I were to have access to your intranet, like intercepting the traffic between my victim users and your server via ARP poisoning, persuading them to try logging on on my machine, or just bribing them. :) But with my nitpicking-security-paranoia hat on, the solution is not ideal. > This is important because $s and $c get stored in the cookie. Why $s? Surely you'll only store $c in the cookie, otherwise there's no point in encrypting the data. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
