Creating constants on the fly. Possible?

[eluser]dionysus[/eluser]
Is there a way to dynamically create constant variables on the fly?

The idea is that upon logging into the system, a user would be asked to upload a small text file that would be fread, and assigned to a var that would be accessible throughout the system.

If this is possible, just to be clear, would this variable then only be accessible to that user and only while the session is alive?

Thanks!

[eluser]erik.brannstrom[/eluser]
I am not entirely sure what you are really after. Yes, it is possible to have the user upload a text file and assign the content to a variable and yes, this can be made available throughout the system using sessions.

If you are indeed using sessions (preferably stored in a database) than they will be accessible as long as you keep it alive, and if implemented correctly only that user will have access to it.

Perhaps some more information about what you have in mind would help clear up any other questions you might have.

[eluser]dionysus[/eluser]
Thanks for the reply.

The idea is this:

Data in the db will be encrypted via mcrypt, and the key will be stored on USB thumbdrives. The user will insert the thumbdrive when going to access the system. Upon logging in, the app will prompt the user to upload the key. They will navigate to the thumbdrive and key. Via fopen and fread, the key will be assigned to a global var which will then allow access to encrypted data, and will be used to encrypt new info being entered to the db.
When the user logs out, or session times out, the global var will become once again empty.

Thanks again!

[eluser]erik.brannstrom[/eluser]
Interesting! Basically, what I wrote previously still stands. Read the file and store the contents in the user session. Make sure you've enabled database session storage though, and you probably should consider encrypting that data also since you are obviously going for a high-security environment. After that, it'll be a breeze to encrypt and decrypt data.

Still, I know there are quite a few people on the forums well-versed in web application security, and perhaps any one of those has more to say on the issue?

[eluser]dionysus[/eluser]
I suppose I could store the key in a session var, but for some reason I keep coming back to the idea of defining a global variable after the file is read. Doing some research, it isn't clear if this is possible nor practical. I'm not clear on how to assign it (fwrite could ostensible write an include file that could be called via require; this wouldn't be temporary though and would live beyond the session -- no good for this application).

Thanks again for your help.

[eluser]Doodlez[/eluser]
I don't think that that would add any more security to your website. It would still be prone to the same issues that a user name password scheme would be.

I'm curious about the idea though I always think things like this are fun. Is there a reason that you want to use this scheme?

Also if you are going to do something of that nature for Added security you would store it in a DB along with the Ip and the log in times of the user.

Check these out.

http://ellislab.com/codeigniter/user-gui...sions.html

http://stackoverflow.com/questions/26964...ure-log-in

[eluser]jedd[/eluser]
[quote author="dionysus" date="1273359931"]
Data in the db will be encrypted via mcrypt, and the key will be stored on USB thumbdrives.
[/quote]

What happens when the user loses their USB thumbdrive? (Or it gets stolen or corrupted or (etc).)

Via fopen and fread, the key will be assigned to a global var which will then allow access to encrypted data, and will be used to encrypt new info being entered to the db.

Try not to define your problem in terms of the solution you've already come up with (f.e. fread() being a key <npi>component).

There's nothing hugely challenging about the technical aspect of what you're trying to do - broken down it's simply a matter of how you authenticate in the first place (and indeed why), how you securely transmit the encrypted key (the whole thing or just the public part of it?) which might include questions about ssl/tls, revoking public (when the user loses their thumbdrive) and of course if/where copies of private keys are kep, and so on.

Receiving a file and storing the contents into some variable that is accessible for that user and that session - is the well-trodden path here.

[eluser]dionysus[/eluser]

What happens when the user loses their USB thumbdrive? (Or it gets stolen or corrupted or (etc).)

The key will be stored on a Trucrypt encrypted volume on the thumbdrives. The key will also be shared among all the users (data needs to be accessible to everyone). Backup key will be stored offsite, just in case.

There's nothing hugely challenging about the technical aspect of what you're trying to do - broken down it's simply a matter of how you authenticate in the first place (and indeed why), how you securely transmit the encrypted key (the whole thing or just the public part of it?) which might include questions about ssl/tls, revoking public (when the user loses their thumbdrive) and of course if/where copies of private keys are kep, and so on

.

All data will be transported to/from the clients via SSL. The system is closed (internal only) and user revocation will be based on initial authentication as well as via trucrypt. Since the key will be stored in a trucrypt volume, the user will never actually see the key. If they leave, the drive will be deleted. The drives will be kept in a safe in the office; they will not leave the building, so losing them isn't a concern.

Receiving a file and storing the contents into some variable that is accessible for that user and that session - is the well-trodden path here.

I understand -- which is why I came to seek the guidance of the CI sages. My problem with storing them in session variables is cookies and limited size. I'd prefer it if the key was only held in memory somewhere and vanished when the session expired or was ended. Cookies scare me here.

So I was thinking that upon logging in, a user would be prompted to upload the key. The key would be placed in a temporary folder. The path to the key would be stored in a session variable, and file_get_contents() would be used in the models when needed to encrypt/decrypt data. When the session expires or is ended the app would unlink() the file.

Thanks very much for your reply.

[eluser]jedd[/eluser]
Hi Dionysus,

Sounds like key revocation could be challenging - having to change all the USB drives seems cumbersome.

How will the contents of the TruCrypt archive be retrieved in a way that means the user can't access the key? (I did some work with TruCrypt a few years ago for laptop users on an NDS network - there's a stack of gotchas with this stuff.)

I understand -- which is why I came to seek the guidance of the CI sages. My problem with storing them in session variables is cookies and limited size.

You've got about 4K, I think, in a standard cookie - but if you use the db-backed stuff (read up on the Session page if you haven't already) then you don't have a limit per se. OTOH it will definitely breach your 'only held in memory somewhere' requirement. OTOOH the concept of stuff being held in memory only and never being written to the disk is a bit misleading - unless you can configure all the client machines to have their swap file / partition encrypted. (I do this on my machines, but it's non-trivial for most users.) The point is that avoiding cookies in an attempt to keep the (encypted) contents of them from ever being written to mag media is not necessarily guaranteed to give you the result you're expecting.

[eluser]dionysus[/eluser]

Sounds like key revocation could be challenging - having to change all the USB drives seems cumbersome.

Well, there are only 10 users so it wouldn't be too bad. The temporary solution is to do it manually (which would probably only take 10 minutes or so). In the long term, I'd like to try to find a way to do it through a script handled by Active Directory/Group Policies, but that is way down the line.

How will the contents of the TruCrypt archive be retrieved in a way that means the user can't access the key? (I did some work with TruCrypt a few years ago for laptop users on an NDS network - there's a stack of gotchas with this stuff.)

Actually the key itself would be an encrypted string that would be decrypted by a key stored on the server. So in the event that a user were savvy enough (none of ours currently are) to open the key file, they'd only see the cipher. This also handles the issue of unencrypted swap space (but I'll look into this -- cryptoswap looks interesting -- thanks!). The idea being that even if the server were rooted, the only key they'd find would only be usable to decrypt the key that is encrypted by trucrypt on the thumbdrives... I'm losing myself here I guess the more abstraction the better.

You've got about 4K, I think, in a standard cookie - but if you use the db-backed stuff (read up on the Session page if you haven't already) then you don't have a limit per se. OTOH it will definitely breach your 'only held in memory somewhere' requirement. OTOOH the concept of stuff being held in memory only and never being written to the disk is a bit misleading - unless you can configure all the client machines to have their swap file / partition encrypted. (I do this on my machines, but it's non-trivial for most users.) The point is that avoiding cookies in an attempt to keep the (encypted) contents of them from ever being written to mag media is not necessarily guaranteed to give you the result you're expecting.

Indeed. Which is why I had the idea of storing the path to the key, instead of the key itself in a session variable. I'd much more prefer to rely on the characteristics of the server which is a linux box than the client machines which are Windows (I have a better understanding of the underbelly of linux) insofar as holdling the actual key. This way I can be sure to delete any instance of the key when it's not needed anymore.

Thanks!