NYCPHP Meetup

[Brian Pang]

No matter what security you put in place, there is always the risk of
Sydney Bristow punching and kicking her way past security in her
high-heels, only to retrieve the data with a device that needs only to
be placed near the HD to read it and upload it to the SD-6 mainframe via
an undetectable satellite uplink where it will be child's play for
Marshal to decrypt.

:)


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