[BW-dev-discussion] Encrypted user data and other security concerns
Jose Aliste
jose.aliste ...
Mon Oct 15 09:47:25 UTC 2007
Hi,
I would like to enlarge a bit the discussion about security concerns. Don't
be mad at me because of repeating what you already have discussed or agreed
or even done.
If a hacker actually has access to the database, I imagine the following
situations:
1. Because of a problem with the DB server, he could fool the server to
connect to it and do normal querys on it.
This case should be managed by restricting the connections on the DB server
only to the apache server(right now localhost?) and having a firewall to
block all connections from outside, but I think it is like this already, or
another similar solution, can a server administrator confirme this?
2. SQL injection in the BW Code.
3. He gained shell access to the machine.
Other situations come to your mind?
So why we want to encrypt the data? I think that at least by case 2 we
should do it!!!!(is there a discussion about how to write "injection"-safer
code under platform pt?)
My biggest concern with the current solution proposed by Felix is the fact
that you have to store a PLAIN master key somewhere in the server. Where are
we going to store it? Under case 3, the current solution is of no utility
as if the hacker had access to the machine, it would be easy to him to find
the master key and then decrypt the DB. I know case 3 is really really hard
to happen but it can happen and we should be aware against which case we are
really protecting our data.
I keep now comenting about the current proposal. One plus for using the
users' passsword is that you don't need to save this password(you save the
hash of it just to check login) but if the user forget his password then you
are forced to use the master key to decrypt the data and reencrypt it using
the new user's password,
So I don't think it is convenient to have two encrypted texts, because in
the end you always would use the master enrypted text, and also as
mentioned, keeping the password(or some salt of it) in the session could
possibly add some other security problems( Some important already mentioned
concern is that the password in BW is currently being sent plaintext!!! so
we should care about not doing this).
I don' think that private-shared keys work well here because you have to
save the private key somewhere(you can't save it in the DB because obvious
reasons unless the key has a passphrase but then you are encrypting using
password again and you wont gain in security IMO) and you can't demand a
user to create a private key in every computer he uses.
So, to resume, i think that we should encrypt using only one master key but
I don' know where we should save this master key!!!(already mention some
concerns but also because you would have it in memory to encrypt and
decrypt and so you could possible get it with some luck and hacker skills).
About case 3 the only thing you can do is to have your server with a rock
solid long term distro with supported security updates.
Another question I have, here it s been said that the data is encrypted when
my profile is not public and not when it is public. As for me, I dont want
my profile to be public and I dont want to show a lot of my data to any
member of BW, but I could like to show some of the sensitive data(as my
name) to some of the members(or maybe all)... personalising what is to be
share could be a good feature but this doesnt go along with the encryption
process.
Another thing more teckie about current implementation is that although I
like the idea of having the encrypted data in other tables, maybe it's
better to have the encrypted data in the same table that it belongs,
something like in the members table for name have 'Joe Doe' if it is not
encrypted or #ENC#"'xqdseazeazeé"& if its encrypted instead of seing the id
of the row in the encrypted table. I think this could save some code logic
as we could add some magic to the Platform PT to automatically decrypt the
data and show it. Maybe I not getting the point here, but I encrypted data
is not only for abuse team no???
Ok, its a long mail but I hope I stayed in topic.
Greetings
José
2007/10/14, Felix van Hove <fvanhove at gmx.de>:
>
> Thomas Goorden wrote:
> > There seem to be a few things wrong here. Comments inline.
> >
> > On 10/14/07, Felix van Hove <fvanhove at gmx.de> wrote:
> >> During login process we could add a letter (or another salt) to the
> >> password, generate a hash of it and could use this for en-/decryption
> >> (instead of the password needed for login). So even if you're able to
> >> isolate the session environment of an administrator, you wouldn't get
> >> her/his password.
> >
> >
> > That seems like an overly complicated setup and doesn't solve the
> problem at
> > all: if the session is compromised, you can still use this hash to
> decrypt
> > the database. The actual password is irrelevant at that point. You just
> > switched the keys to the lock.
>
> May be we misunderstand each other. The password used by the
> administrator while login is only used for encryption/decryption of the
> profile data of the administrator.
>
> The administrator has access to a master key by her/his login. (The
> access though is completely transparent. Neither the member key
> (password) nor the admin key is ever transmitted to the member.) This
> key enables the admin to read/write all data. This master key isn't in
> the session environment of the administrator.
>
> >
> > We should make sure admins change their passwords frequently anyway.
> >> Possibly we could reduce their session timeout to 4 minutes too.
> >
> >
> > How can you enforce that if the database is encrypted using this
> password?
> > You'd have to re-encrypt the entire database for a password change.
>
> As I said: The password of the administrator is not the same as the
> master key.
>
> >
> > Public-/private key procedures aren't an alternative afaik. They need
> >> keys much longer than the 10 bytes of a password.
> >
> >
> > Not true. A public key might be long, but we can store that in the
> regular
> > user profile. They don't ever need to enter it. The private key can be
> > small, I'm sure that can be done.
>
> Please help and provide an example of asymmetric encryption with a
> private key length less than 10 bytes.
>
> >
> > How do you solve the encryption with two different passwords?
>
> There's only one password for each member (admin or not).
>
> Felix
>
> >
> > Thomas
> >
> > Felix
> >> Callum Macdonald wrote:
> >>> I think encrypting private data, presumably twice, is an unnecessary
> >>> step. Plus, I'm certain that storing a user's password in the session
> >>> introduces a whole host of other security issues.
> >>>
> >>> Has anyone researched the overhead required to encrypt and decrypt the
> >>> data? I suspect this will become a significant issue as the
> application
> >>> scales. Unless we can hand off encrypted data to a separate server
> >>> (which adds other challenges) I think we're going to see server load
> >>> skyrocket when handling encryption.
> >>>
> >>> I think it's an unnecessary additional step and would vote to remove
> it.
> >>>
> >>> Cheers - Callum.
> >>>
> >>> Peter Lind wrote:
> >>>> When signing up you have to private data so that you can be
> >>>> identified. Such as address and age. Maybe you don't want everybody
> to
> >>>> know these things. Maybe you want privacy. Hence, they're encrypted.
> >>>> However, as some volunteers will need to be able to check these
> >>>> things, some admins have to be able to access this data. Otherwise no
> >>>> abuse-team.
> >>>>
> >>>> What you're achieving by encrypting the data is two-fold:
> >>>> - in the event that the database is accessed by a hacker or stolen,
> >>>> the personal data is not leaked but stays private
> >>>>
> >>>> Kind regards
> >>>> Peter
> >>>>
> >>>> 2007/10/13, Callum Macdonald <bw-lists at callum-macdonald.com>:
> >>>>
> >>>>> Hi Felix,
> >>>>>
> >>>>> I'm not clear on specifically what data is encrypted though. Which
> >>>>> actual fields?
> >>>>>
> >>>>> I'm still unclear of why a user would choose to store data in the
> >> system
> >>>>> if only they can access that data. Why would they upload their
> private
> >>>>> data if they don't want other users to see it?
> >>>>>
> >>>>> I'm also unclear on the value of encryption if the site admin can
> >>>>> decrypt the data. What are we achieving by encrypting the data?
> >>>>>
> >>>>> Cheers - Callum.
> >>>>>
> >>>>> Felix van Hove wrote:
> >>>>>
> >>>>>> Hello Callum,
> >>>>>>
> >>>>>> Sensitive user data is supposed to be stored encrypted in database.
> >> An
> >>>>>> exception are users, who did this:
> >>>>>>
> >>>>>> "My Account" - "My Preferences" - "Public profile" click "Yes"
> >>>>>>
> >>>>>> If you explicitly declare to make your profile accessible to
> public,
> >>>>>> your data won't stored in an encrypted format.
> >>>>>>
> >>>>>> Of course a user needs to access her/his own data even in the case,
> >>>>>> she/he doesn't want to publish it. E. g. I sometimes want to change
> >> my
> >>>>>> profile data - the hidden data is also subject to change.
> >>>>>>
> >>>>>> We use the password (which is put into the session of the member)
> to
> >>>>>> decrypt and encrypt this data.
> >>>>>>
> >>>>>> We additionally use a master key to ensure an administrator of the
> >> site
> >>>>>> can access all data as well.
> >>>>>>
> >>>>>> Please have a look at the code. The code is telling more than
> >> everything
> >>>>>> else. Although I must admit the encryption strategy is subject to
> >> change
> >>>>>> as well - as you can see by browsing the new module (which isn't
> used
> >> yet).
> >>>>>> So long,
> >>>>>> Felix
> >>>>>>
> >>>>>> Callum Macdonald wrote:
> >>>>>>
> >>>>>>
> >>>>>>> G'day,
> >>>>>>>
> >>>>>>> On the discussion about openID there was talk of user data being
> >>>>>>> encrypted, and only decrypted while the user is logged in. I'm
> >> curious
> >>>>>>> as to what data is encrypted, and I'm struggling to understand why
> >> any
> >>>>>>> data would be encrypted at all.
> >>>>>>>
> >>>>>>> Can anyone shed any light on it?
> >>>>>>>
> >>>>>>> Cheers - Callum.
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> bw-dev-discussion mailing list
> >>>>>>> bw-dev-discussion at bewelcome.org
> >>>>>>> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> bw-dev-discussion mailing list
> >>>>>> bw-dev-discussion at bewelcome.org
> >>>>>> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> bw-dev-discussion mailing list
> >>>>> bw-dev-discussion at bewelcome.org
> >>>>> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
> >>>>>
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> bw-dev-discussion mailing list
> >>> bw-dev-discussion at bewelcome.org
> >>> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
> >>>
> >> _______________________________________________
> >> bw-dev-discussion mailing list
> >> bw-dev-discussion at bewelcome.org
> >> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
> >>
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > bw-dev-discussion mailing list
> > bw-dev-discussion at bewelcome.org
> > http://bewelcome.org/mailman/listinfo/bw-dev-discussion
> _______________________________________________
> bw-dev-discussion mailing list
> bw-dev-discussion at bewelcome.org
> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://bewelcome.org/pipermail/bw-dev-discussion/attachments/20071015/a6e766bf/attachment.html
More information about the bw-dev-discussion
mailing list