On Jul 12, 2006, at 6:20 PM, John Tregea wrote:
Thanks for your extensive reply. The point you raised about info
leaks through memory was one of my two concerns, the other was what
could be seen by 'peaking' into the built application.
In the latter case, you are using a hardwired password. From my
understanding of your recent mail, you don't want to do that. Well,
not completely.
I guess I can overwrite the memory variables I use by setting them
to empty at the end of each handler.
First put a string of the right length into char 1 to -1 of the key.
That will write over the key in RAM. Now you might have
inadvertently made copies by then.
I planned to do that when the user logs out anyway. I also was
going to store the variables in custom properties (in encrypted
form) during the session and set them to empty at the end of a
session.
Why not a global? If the file gets saved, you don't want them in
properties.
Really there is just two things that have to be stored in the Rev
side of the solution. That is the login user name and password for
the postgreSQL database. Once the connection is made through that
default account, there is a two, three or four factor validation
process from within POstgreSQL.
If the user login is not used for data encryption, you do not need to
keep any copies anywhere. Use a digest such as MD5. Even then you
might need to have an ephemeral copy after it is keyed in, but there
are ways to avoid that.
You can prevent entering of the db password until the user login is
complete.
Earlier you had mentioned encrypting of data in the db at the client
end. If the user does not supply the password for that, then it is
essentially and extension of your program and is as vulnerable as that.
I realised that I may be able to use the location of certain
objects within the front end to build the key. The objects never
move in relation to each other and the resulting string of numbers
would be a perfectly hidden string.
maybe something like
repeat with x = 1 to the number of btns put char 1 of the short
name of btn x & item 1 of the loc of btn x after tTheKey
if length(tTheKey) > 16 then exit repeat
end repeat
put char 1 to 16 of tTheKey into tTheKey
-- the key would end up something like b234t256h678f67u (a 128 bit
key)
?
I would have to be careful that the stack window never has a new
button inserted at a low layer in subsequent versions, or the
clients would lose there data decrypt capability :-)
You can put a little time into obfuscation, but I wouldn't put a lot
into it. If this is used to hide the data encryption key, then your
encryption is no better than a light scrambling. If this level is
fine, then this approach is fine.
The above method has the cool feature of being a sort of application
digest, though.
Any thoughts?
Consider these questions. The answers might affect your approaches.
Is the server physically secure? Is the client computer physically
secure? The network between? Is there a risk of eavesdropping on
the network? Is there a risk of man-in-the-middle on the network?
Is there a risk of a fake login to the db server? Will people lose
the ability to log in and access data? Why does the data need to be
encrypted at the client? What encryption does the db support? What
are the actual standard requirements? Are redundant layers needed?
If the data needs to be encrypted by the clients and decrypted by the
clients, then you might as well use a secret key. You can have the
key kept at the client or kept at a key server. In the first case,
it needs to be encrypted with a user password (optionally mixed with
your obfuscated application key) or derived from it (and optionally
mixed). In the second case, you still need a user password. The
second case might allow for encryption password management and handle
login and db password management, too. You can also break up the
data into encryption zones and only provide the keys for the zones
used by that user.
You said it yourself. Believe it. If you hide the key using
scrambling level obfuscation, then you reduce your mil-grade
encryption to scrambling level. You can claim little about the
encryption.
Dar
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
