NYCPHP Meetup

[David Sklar]

If you are not providing any automated processes that do decryption, then
you don't need to store the key anywhere (but in the head of the admin).
This is good (and TEA or Blowfish or whatever will probably just fine for
your encryption).

What do you mean by "shared-database"? Are there users out of your control
who have read access to the tables in which this data is stored? Or are you
dependent upon a third party's correct administration of database access
privileges to ensure that other people can't look at the relevant database
tables. If you are storing the key anywhere, then the encrypted data is only
as secure as wherever the key is (as you noted below). So if you are storing
the key in a file whose proper security depends on a third-party
administrator, you may not be better off than just storing the data under a
permissions regime that also depends on such an administrator.

At some point, the data is valuable enough to put it on a dedicated server,
so that unauthorized access requires either a nasty hole in your application
that exposes it or physical access to the machine.

Then you have to start thinking about unauthorized physical access. There
are lots of ways to make yourself comfortable in this regard, but part of me
keeps thinking that being on the overnight janitorial shift at a large
company or hosting provider would be a very lucrative job -- a USB DVD
writer and a few minutes access to a machine would provide access to lots
and lots of data that would be very valuable.

David


On Tuesday, September 02, 2003 2:28 PM,  wrote:

> 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
>>
>>
>>
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk