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. ___
[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.
___
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On Tuesday 14 November 2006 13:28, Crispin Cowan wrote: > It means that compromising performance It's not necessarily a given that runtime performance is compromised. There are situations where Java is faster than C (I've tested this on trivial things). I'm sure there are situations where the reverse is true, too. But as new releases of the JVM come out, all Java programs get faster. Personally, I find the programmer time to be much better used in Java too. That is less of a factor of the VM side of things (although you can do some really quite nice debugging things by communicating with the JVM which helps), but it does tend to be a feature of things that predominantly run inside some non-native environment. I don't know if there's a causation effect going on there or not however. > to obtain runtime portability > that does not actually exist is a poor bargain. The runtime portability is not perfect. The problems mostly exist where it interfaces to the underlying system, and where that's done imperfectly. Not so long ago, I ported a commercial desktop Java-based application from Windows to Linux. It took me a day or two to go through all the references to File, and make sure they were constructed properly (i.e. replace instances of '\\' with a properly constructed File) and do some testing, and that was all. It then looked and behaved just the same as it did on Windows, and objects could happily be de/reserialised across the different platforms (and on different architectures if necessary). However, you never have to deal with different word sizes, different endians, and so on. It removes as many of the gotchas as is feasible. Back on the security topic for a moment, you also gain things like sandboxing that works in a way that isn't reliant on the capabilities of the hardware. Robin. ___ 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
Re: [SC-L] Fwd: re-writing college books - erm.. ahm...
On Tuesday 07 November 2006 16:42, Julie J.C.H. Ryan wrote: > Folks, I've been forwarding select messages from this listserv to my > nephews, who are undergrads in CS at some fairly reknown I did a CS degree quite recently. There was simply _no_ mention of security, with the exception of passing mentions in the software engineering paper. In my 4th year (first year of postgrad), I did a paper on network security that was run by the information science department[0] for my own edification. A good paper, although it didn't cover software development security at all (and didn't intend to, either). A large amount of the programming done there is in safer languages, however. I was in the last year doing Pascal, now it's Java. They are taught C later more to give students exposure to something a bit 'closer to the metal', where less of the donkey work is taken care of. After that, it tends to develop more into specific languages as suits what people are doing (haskell, prolog, LISP, etc). It is important to note that there is no goal of teaching students to go off and be safe programmers. Computer science is seen to a reasonable extent to be a theoretical persuit. Algorithms are covered, GC methods, heuristical searchs, and so on. That many students from this tend to go off and become programmers is almost seen the same as if they went off and became plumbers, just much more common. They are, of course, expected to hang around and become academics ;) You could reasonably argue (and I'm inclined to believe it myself) that not teaching secure practices to computer science students is a problem, but I think that the underlying issue is more that security is more of a vocational thing, the same as if they were to teach, say, programming with EJB. (Note: I consider many branches of security research to fit fairly comfortably into computer science, but I don't think that things like 'avoiding buffer overflow vulnerabilities' do, the usefulness of the knowledge aside) None of this is to say that it shouldn't be taught, just to provide my opinions on why it's not taught. Given a large number of CS students _do_ go off and develop real-world software, security should be given some time. Aside: I don't think there's anything wrong with printf in Java, it is helpful, and AFAIK it's not prone to the same format string vulnerabilities as C is. [0] at my uni, information science is the more business/application-oriented computer-related department, computer science is much more like applied mathematics/biology/cognitive psychology, depending on what exactly you're doing. -- 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 pgp6P11RfRznB.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
