Hi John I have not played around with the encryption, but to my knowledge this is not the way it works. The password is related to the data encrypted, not to the user, so every user would require the same key for the data. To change the key you need to unencrypt and reencrypt the data.
The other option is encryption at rest where the whole database is encrypted. This has been greatly enhanced in Rel11 of UniVerse. Regards David Jordan -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Thompson Sent: Monday, 12 September 2011 10:35 PM To: U2 Users List Subject: Re: [U2] ENCRYPT in Universe As far as passwords are concerned, I could use their password as the key? That way it would be different every time, and in order for it to be decrypted, they would have to supply the right password, otherwise, they would have to reset it... Is that a decent way of doing it? I've also noticed that in the manual they seem to have encrypted files, where this is handled "somewhat" automatically. But all of that seems much more complex to manage than this ENCRYPT() BASIC function. I think... Anyone ever use the encrypted file/field commands from TCL and had any luck with them? It appears you have to jump through a lot of hoops form upgrade to upgrade though, which I'm not too fond of. On Fri, Sep 9, 2011 at 9:25 PM, John Hester <jhes...@momtex.com> wrote: > The key can be any text string you want and it's completely up to you > how you store it. I would use a long, random mix of characters. The > most secure place to store it would probably be on removable media > that has to be inserted for the application to work, but that's > probably overly inconvenient for most applications. Storing it in the > same file as the encrypted data is probably the least secure place. > Storing the key in a separate file is a relatively secure method, > IMHO. There is some security by obscurity here since only someone > with knowledge of the inner workings of the application would have any > idea where the key is stored. > > It's also up to you if you want to re-use a single key or not. You > could use a different key for every piece of data, but you have to be > able to correctly marry the keys back to the right data to decrypt. > Having another file with data that points to the IDs in the encrypted > file could also tip off an attacker as to what the keys are for. I > suppose you could get elaborate and encrypt the keys themselves, then > the keys for those keys, etc., making it very difficult for an > attacker to determine the decryption sequence. You could also > re-encrypt the already encrypted data a few more times with multiple keys. > > -John > > -----Original Message----- > From: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John > Thompson > Sent: Friday, September 09, 2011 8:44 AM > To: U2 Users List > Subject: [U2] ENCRYPT in Universe > > I am exploring the Universe data encryption features... Its my first > try at this really. > I have decent understanding off ssh and ssl, just not the U2 stuff. > > My questions are... > Where is a safe place to store the "key" (as referred to in the docs) > that the function needs to do encrypting and decrypting? > How would I generate this key? > Do I use the same key every time? > Is there a thing to generate a key... like in ssh? > > For example, lets say I have a program that encrypts the user's > password and then writes it to the data file like so... > > *A test for storing encrypted passwords. > OPEN \BAS.USERS\ TO f_bas_users ELSE > CRT \Cannot open BAS.USERS file.\ > STOP > END > * > CRT \Enter your email address: \: > input email_address > CRT \Enter your password: \: > input password > * > key = \thisismykey\ > result = \\ > encrypt_status = \\ > encrypt_status = ENCRYPT(\des3\, 1, password, 1, key, 1, 1, \\, > \\, result, 1) > CRT user_password > *Apparently a status of 0 is a success. Which is just plain weird. > IF encrypt_status = \0\ THEN > WRITEV result ON f_bas_users,email_address,3 > END > > ---------------------- > Now lets say I want to check the password to see if it is correct and > decrypt the data to do that... > > *A test for reading encrypted passwords. > OPEN \BAS.USERS\ TO f_bas_users ELSE > CRT \Cannot open BAS.USERS file.\ > STOP > END > * > CRT \Enter your email address: \: > input email_address > CRT \Enter your password: \: > input password > * > READV stored_password FROM f_bas_users,email_address,3 ELSE > stored_password = \\ > END > key = \thisismykey\ > result = \\ > decrypt_status = \\ > decrypt_status = ENCRYPT(\des3\, 3, stored_password, 1, key, 1, > 1, \\, \\, result, 1) ; *This is actually decrypting, the 3 indicates > that. > *Apparently a status of 0 is a success. Which is just plain weird. > IF decrypt_status = \0\ THEN > CRT \This is the stored password decrypted from the > file.\:result > CRT \This is the password entered by the user.\:password > END > ---------------- > > So... isn't it kind of pointless to store the key in plain text in the > program? > Storing the key in plain text in the file also seems pointless? > > Thoughts? > > -- > John Thompson > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > -- John Thompson _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
