NYCPHP Meetup

[Chris Snyder]

I'm encrypting smallish strings, probably not subject to attack but 
protected just in case.

1) I want passwords to be encrypted for storage, but decryptable so that 
they can be looked-up by an admin (over SSL) or (gasp!) sent to a user 
via email if the user has agreed in advance that this is a completely 
insecure thing to do.

2) I want to create an encrypted session cookie that includes the 
session id and a shared secret that changes with every request.

3) I'd also like to encrypt identity data like addresses and telephone 
numbers.

This may at some point be used to protect access to quasi-financial data 
(credits in a game economy), but never credit card or social security 
numbers. I know that all of this is dependent on the encryption key 
remaining secret, but in a shared-database environment this seems like 
the right thing to do.

    chris.


David Sklar wrote:

>If you're at the point where the difference between TEA and Blowfish is
>important to your application, then you should read Applied Cryptography.
>
>What are you encrypting? For the differences between algorithms to really
>matter, you should be analyzing how much ciphertext you're generating, who's
>likely to snoop it, what kind of resources they have, etc.
>
>For most web-based services, the likelihood of a bruteforce attack (or
>slightly-less-than-brute-force based on a weakness of a cryptosystem) is so,
>so, so much less than the likelihood of an attack because someone was
>careless and left a key in an accesssible place or chose an easily guessable
>key. A 56 bit key and a 1024 bit key are equally weak when they're written
>on a post-it stuck to a monitor.
>
>David
>
>  
>