Re: [SC-L] Best practices for encrypting client-side data

2007-05-10 Thread Robin Sheat
On Wednesday 09 May 2007 03:00:12 SC-L Subscriber Dave Aronson wrote:
 What happens when the user changes his password?  I didn't quite follow it
 all, but it looks to me like that means that all of a user's data has to be
 decrypted and re-encrypted.  You didn't tell us how much data that is, so
 I'm going to ass-u-me that it *could* be a lot.
Probably not so much that re-encrypting would be a problem. I'm not exactly 
sure how much, it depends totally on how much the end-users use this part of 
the system. I would expect 10s of Mb, maybe into the 100s.

 Perhaps you could base the encryption on more stable data, such as the user
 name combined with when the user joined.  This could be used to encrypt the
 data directly, or, as you proposed, to encrypt the actual key.  How
My issue with that is that it's non-revocable by the user. Should 
bad-guy-Mallory manage to get that information somehow, the user can't do 
anything to protect their future data. If Mallory steals their password, then 
the user can change it, meaning that Mallory has to put the hard-yards in to 
get access back again.

 Also, just how secure do you need it to be?  Don't waste a thousand-dollar
 lock on a fifty-dollar bicycle.  Is this data actually a tempting target
 for attackers who are clueful and resourceful (in both the senses of
 clever and able to spend a lot)?
I think the primary attack scenario is to prevent someone leaving a laptop 
somewhere, someone else picking it up and saying ohh, interesting data! Lets 
sell it to their competitor, but in the interests of 'doing it properly', I 
expect there won't be much more expense on our part to put a more complete 
and secure solution in than that. Perhaps so that if the well-funded 
competitor gets the disk, they can't break it quickly and easily. I'm leaving 
things like planting keyboard sniffers out of the equation. If they can do 
that, they have the user's password and can log into the system and see all 
the data anyway and would have no need to try to defeat the encryption.

-- 
Robin [EMAIL PROTECTED] JabberID: [EMAIL PROTECTED]

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D


pgpjXCPWm5OgA.pgp
Description: PGP signature
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Best practices for encrypting client-side data

2007-05-10 Thread Robin Sheat
On Wednesday 09 May 2007 05:04:53 you wrote:
 You go on to describe (I think) crypto operations that take place
 completely on the client site. What is the relationship between the
 encrypted data and server client-server communications?
For the purposes of this, there isn't. It was just to illustrate the point 
that a password is required and is checked by another component of the 
system. All the crypto (that I'm interested in here) is completely 
client-side.

  * The salt is currently hard-coded. It should be regenerated for every
  encryption operation in order to make it that much harder (question:
  should it be a different salt used for every file encrypted by a user, or
  one salt across all files by that user? Does it matter?)
 You should have a random salt every time you generate a hash or key.
Y'know, thinking about it more, I don't think that a salt would help at all in 
this situation. I'm not storing a hash of the password anywhere, the data is 
encrypted with the hash of the password, and to decrypt, the hash is 
regenerated from the user-supplied password.

...actually, I take that back. It would mean that each file (the data is 
composed of multiple smallish files) would have a different key, so if the 
attacker found the key to one, but not the password, they couldn't get to the 
other files. A small gain, but a gain nonetheless.

-- 
Robin [EMAIL PROTECTED] JabberID: [EMAIL PROTECTED]

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D


pgpleZMK3XBCL.pgp
Description: PGP signature
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Best practices for encrypting client-side data

2007-05-10 Thread Robin Sheat
On Wednesday 09 May 2007 02:11:05 ljknews wrote:
 I would suggest two factor authentication, requiring some smart card
 (with built-in keypad, to prevent intercept of the pin) that actually
 provides the decryption.  Make the user keep the smart card with them,
 such as by requiring it for entrance to the cafeteria or rest room.
That's not possible in this case. Mostly because it would involve more 
investment on our part than the customers would be willing to pay for.

However, I'm interested in generalising the ideas in this thread to go beyond 
my particular situation; if you were storing data in an application on a 
laptop, how would you keep it as safe as is feasible? Especially in the case 
of non-tech-savvy end users and machines out of our control, so we can't do 
things like install truecrypt.

-- 
Robin [EMAIL PROTECTED] JabberID: [EMAIL PROTECTED]

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D


pgpWJu9hzmbvw.pgp
Description: PGP signature
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Best practices for encrypting client-side data

2007-05-10 Thread ljknews
At 12:01 PM +1200 5/10/07, Robin Sheat wrote:
 Content-Type: multipart/signed; boundary=nextPart1622971.NJ1973Q3ia;
   protocol=application/pgp-signature; micalg=pgp-sha1
 Content-Transfer-Encoding: 7bit
 
 On Wednesday 09 May 2007 02:11:05 ljknews wrote:
 I would suggest two factor authentication, requiring some smart card
 (with built-in keypad, to prevent intercept of the pin) that actually
 provides the decryption.  Make the user keep the smart card with them,
 such as by requiring it for entrance to the cafeteria or rest room.
 That's not possible in this case. Mostly because it would involve more 
 investment on our part than the customers would be willing to pay for.
 
 However, I'm interested in generalising the ideas in this thread to go beyond 
 my particular situation; if you were storing data in an application on a 
 laptop, how would you keep it as safe as is feasible?

The tension between as safe as is feasible and not willing to pay for
is not susceptible to generalization.
-- 
Larry Kilgallen
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Best practices for encrypting client-side data

2007-05-09 Thread Blue Boar
Robin Sheat wrote:
 Basically, I needed to encrypt the on-disk format of some data that is 
 accessed as a seekable file (it's actually a Lucene index, but the details 
 aren't too relevant). The use case for this is to ensure the data is kept 
 private, even if the disk or computer the data is on is taken (it's a 
 network-aware client app, so they log in to the program using a username and 
 password).

You go on to describe (I think) crypto operations that take place
completely on the client site. What is the relationship between the
encrypted data and server client-server communications?

 * The salt is currently hard-coded. It should be regenerated for every 
 encryption operation in order to make it that much harder (question: should 
 it be a different salt used for every file encrypted by a user, or one salt 
 across all files by that user? Does it matter?)

You should have a random salt every time you generate a hash or key.

 * Is it wise to use the user's password directly, or should that perhaps be 
 used to encrypt a key, and that key used to encrypt the files? This would 
 certainly make changing the password easier, but if that key is ever 
 compromised, it's a bigger issue.

You can get a little extra security with an encrypted keyfile for
certain attack scenarios if done properly. With your design, if I have
only the encrypted file, I can start brute-forcing passwords
immediately. Might not be practical, depending on how big the salt is,
and whether I got that too.

If there's an encrypted keyfile, I have to steal that too, plus I still
have the exact same amount of brute forcing to do. So, the decisions
depends on whether stealing the encrypted data almost always allows me
to steal the keyfile, or if you can do something significant;y better,
like having the user store the keyfile on a USB drive or the remote
server or something.

In order to not have created an irrevocable encryption key, every time
the user changes their password, you should create a new encryption key
and re-encrypt the data with that key, rendering the old stolen keyfile
useless.

 
 * The Java crypto system looks like black-magic. I haven't seen many things 
 that talk about how to use it well. How do I know I'm not using it in some 
 vulnerable fashion?

I can't help you there. I know nothing about Java's implementation
details, nor can I tell if you've created a stream cipher that can be
decrypted by XORing with itself or something else silly.

Ryan
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Best practices for encrypting client-side data

2007-05-09 Thread SC-L Subscriber Dave Aronson
Robin Sheat [mailto:[EMAIL PROTECTED] wonders:

  What I did was take the user's password to create a key

What happens when the user changes his password?  I didn't quite follow it all, 
but it looks to me like that means that all of a user's data has to be 
decrypted and re-encrypted.  You didn't tell us how much data that is, so I'm 
going to ass-u-me that it *could* be a lot.

Perhaps you could base the encryption on more stable data, such as the user 
name combined with when the user joined.  This could be used to encrypt the 
data directly, or, as you proposed, to encrypt the actual key.  How difficult 
would it be for the attacker to figure out whose data something is, and when 
they joined, or whatever else you base your encryption on, AND the fact that 
that's how you encrypt?  If finding that out would be pretty much trivial, 
there goes all your protection, under the above scheme.

Also, just how secure do you need it to be?  Don't waste a thousand-dollar lock 
on a fifty-dollar bicycle.  Is this data actually a tempting target for 
attackers who are clueful and resourceful (in both the senses of clever and 
able to spend a lot)?

-Dave

-- 
Dave Aronson
Specialization is for insects.  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___