personal information storage question

[Kent Borg]

Eric Chadbourne wrote:
> I have a couple of local small insurance companies that need their 
> websites redone.  Looks like they are going to let me do it.  Are there 
> any industry specific security standards i have to be concerned with? 
>   

The credit card people have some (I think) public standards that might
be worth looking at.

> Such as with an HTML form that collects info for a request for a quote?
>   

Don't talk to children. Some specific laws about that. European laws can
be very strict, they probably don't apply to you, but might be worth
Googling to get you thinking.

> Thanks for any tips!
>
> Eric C - the one who wants to encrypt everything.
>   

Yes on encryption. I would start with running everything over https,
even the home page. Immediately redirect from http. (There are ways to
do man-in-the-middle if one can grab the http connection first--people
don't watch for the httpS and the padlock isn't really paid attention to
and there is room for at least partially faking them). Don't trust that
https is completely secure--what if the CA is served with a court order
to supply keys?

There will be some spots in the middle of your system where maybe
information should be hashed so it can't even be decrypted. If you don't
store any information you don't need to store, then you can't lose it.

In addition to any encrypted or hashed data in the system, run the whole
thing on encrypted disks so that there isn't a disposal problem.

Avoid dangerous languages that make buffer overflows easy. Don't trust
any input from the outside world, interpret all entries as narrowly and
un-automatically as possible. I was once appalled by security problems
with PHP, I forget the details, maybe it was register_globals which now
defaults off...

It seems all end-user security problems come in via Javascript (though
Acrobat seems the new juicy target), maybe don't use Javascript and so
do you part in not making that problem worse. Maybe you don't need
cookies either--embed any session information in the URL, make returning
users authenticate again (if there is any such concept in your system).

If you do passwords there are smarter ways to do that, such as not
letting the user choose his/er password (and so not let users recycle
passwords across multiple sites). Also, asking for only a few specific
characters of the password limits how much information is lost to a
spyware program. (I have seen a bank that does both of these.)

If you are going to be more conventional, certainly allow long
passwords, hashing passwords is smart if you don't aren't doing the bank
trick above. (And even if you are, there might be some cryptographic
cleverness to make that more secure, too. I would have to think about
that more.)

Make a point of staying ignorant of the actual encryption keys you use
to build the live system so that by changing passwords on the encryption
of the keys, you can have your own access conclusively shut off. At some
point you don't want their site to be your problem, plan for that.

No mater how much effort you put into security, do an analysis of your
security (of greater or lesser depth, as is appropriate). Think through
what you do well, figure out what your weak spots are, make some
explicit guesses as to who your likely foes might be and how powerful
and motivated they might be, figure out the costs of a failure, and
tally it all up. Make sure your exposure and precautions are
appropriate. You might just do this for your own benefit, or you might
have a customer who is actually interested in the analysis. There is no
such thing as "secure", if nothing else there is the question of where
you draw the boundary line, what do you consider under your control and
what is external. Every system has weaknesses, redefining the boundaries
is one avenue of attack.


-kb, the Kent with tons of security opinions.