Re: [SC-L] Best practices for encrypting client-side data
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
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
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
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
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. ___
Re: [SC-L] Best practices for encrypting client-side data
At 10:09 PM +1200 5/8/07, Robin Sheat wrote: > Content-Type: multipart/signed; boundary="nextPart6783111.ysaAiqc79P"; > protocol="application/pgp-signature"; micalg=pgp-sha1 > Content-Transfer-Encoding: 7bit > > I'm no security professional, just a programmer with a healthy interest in > it, > most of what I've gleaned has come from lists such as this, and the various > securityfocus ones. > > A little while ago I was asked to implement something that I didn't have much > of a low-level idea of, so I hope here is an appropriate place to ask. > > 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). There should be concern that the computer might be temporarily stolen to install a keyboard sniffer and then returned for long enough to scarf up the password. What protections do you have to prevent the user from choosing the same password for some _other_ system ? The smart thief will obtain the user password before stealing the box. 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. Obviously other smart card features are in order, such as going dead after N bad tries at the pin, and a duress code. -- 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
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. ___
[SC-L] Best practices for encrypting client-side data
I'm no security professional, just a programmer with a healthy interest in it,
most of what I've gleaned has come from lists such as this, and the various
securityfocus ones.
A little while ago I was asked to implement something that I didn't have much
of a low-level idea of, so I hope here is an appropriate place to ask.
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).
What I did was take the user's password to create a key (Java follows):
paramSpec = new PBEParameterSpec(salt, iteration);
PBEKeySpec keySpec = new PBEKeySpec(password.toCharArray());
SecretKeyFactory kf = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
key = kf.generateSecret(keySpec);
this key is then used to initialise a cipher. The IV for the cipher is created
by the Java crypto system, and that is then written to the head of the
stream. Following that is an encrypted 'magic number', and the encrypted
data. Note that this happens when the file is closed, in the interim it is
buffered in RAM (due to the need to be able to seek anywhere within the file
while writing).
Decryption follows an (obviously) similar process, the key is generated as
above, the IV is read from the head of the stream and used to start the
cipher going, the magic number is checked to ensure it is what it should be
(so I know that decryption is happening correctly), and then the stream is
read and decrypted into memory.
There are some maybe-issues I'm aware of, but I'm not confident in my ability
to tell how significant they are, I'd appreciate any suggestions or comments.
* Buffering in RAM is an issue as it could get swapped out etc. I'd like to
know of any recommendations for creating a seekable, encrypted file.
* 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?)
* 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.
* 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?
* Is it OK to have the IV exposed like that, or should it be kept hidden
somehow? The impression I have is that it's OK for it to be known, so long as
it changes every time the file is written.
I know this is a bit off the vulnerability theme that this list often takes,
but I hope it's considered relevant enough to dig up some input.
Cheers,
--
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
pgpgIhTRygXHV.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.
___
