Limiting access to password files

[Jon Swanson]

I've had a request to password protect a program. In my mind there are two parts to the problem- generating and authenticating usernames and passwords, this seems straightforward and there are plenty of examples on the web, and restricting access to who can create and manage the usernames and passwords.

I may just not be thinking about this correctly, but my desire would be to have a program requiring administrative access to generate new username/passwords and only allow the program and the administrator to see the file/database where these are stored.

I will be running Windows 7/8/10 and have not had any luck allowing Java to run in an administrative account or run AUC.

Before I go too far down this path, could I get a little help understanding what people do?

[Campbell Ritchie]

Please tell us what tools and platforms you are using; the process is different if you have a database, for example.

[Jon Swanson]

Sorry, should have been more specific. Though at this point I am pretty flexible. I have a Java program that is started java -jar program.java. There is no password support in it right now. I was thinking of generating the password with PBKDF2 and Salt. I don't think creating a hashed password to store should be a problem. I'm just not sure what a good process is for getting the passwords initially created and then accessed by the program. There will be no database server running, I prefer not to edit the Windows registry. Short of that, there are no restrictions except  I am running on Windows. This application runs locally, there is no web/cloud component. Is this helpful? I am not sure I know enough on the topic to ask a good question and Google has not been helpful.

[Stephan van Hulst]

Why not just use Windows' built-in security and just prevent users from executing the application unless they've been granted rights?

[Campbell Ritchie]

But that approach compromises Java®'s platform‑neutrality.

[Tim Holloway]

Campbell Ritchie wrote:But that approach compromises Java®'s platform‑neutrality.

However, the venue was explicitly stated as the (obsolete) Windows 7, 8 (eek!) and 10. So it's not neutral.


Fair warning. I consider "password generators" to be suspect. Too often, host-generated passwords are horrible abominations that are hard to type and hard to remember and frequently end up written down on sticky notes attached to the monitor. The other day I had to copy a password over to a notepad program because I couldn't even tell if the "|" in it was a 1 or a lower-case l, thanks to the font that was on the GUI.

Security experts hate these sorts of passwords, since they've been proven less secure than plainer longer ones. And because they do often end up posted next to the computer in full public view.

The best way to "limit access to a password file" is to use an authentication service. That way, the security tokens - and mechanisms - are completely isolated from the user. It's the difference between using SQL to "SELECT password FROM users WHERE USER_ID = ...:" and locally comparing the password that was returned and "SELECT COUNT(*) FROM users WHERE user_id=? AND password=?". One leaks exploitable data back to the client and the other only tells you whether the submitted password is valid or not.

In Windows, as Stephan has said, the primary authentication and authorization is already in the OS. If you want something that is more neutral and after-the-fact, you can hook into an external system such as Kerberos. Which is (allowing for some abrasion by Microsoft) actually what Windows Domain Security itself is. But Kerberos is also common on Unix and Linux networks.

[Campbell Ritchie]

Tim Holloway wrote:. . . However, the venue was explicitly stated as the (obsolete) Windows 7, 8 (eek!) and 10. So it's not neutral. . . .

That's all right as long as the user intends only to run the app from a particular computer, or at least from a particular OS.

[Stephan van Hulst]

Campbell Ritchie wrote:But that approach compromises Java®'s platform‑neutrality.

It doesn't, because you don't change the application. You just use the operating system as it was intended to be used. Most operating have a way to limit access to files to certain users, even across multiple systems if the user is part of a domain.

[Campbell Ritchie]

Thank you

[Tim Holloway]

Campbell Ritchie wrote:

Tim Holloway wrote:. . . However, the venue was explicitly stated as the (obsolete) Windows 7, 8 (eek!) and 10. So it's not neutral. . . .

That's all right as long as the user intends only to run the app from a particular computer, or at least from a particular OS.

And we know that no Very Important User is ever going to get a computer that runs MacOS.  

[Jon Swanson]

Thank you all for the discussions.

A quick aside- I have an interesting environment in that software is often run on the computers that also run the analysis hardware. The vendor of the hardware supplies software that does not run on Windows 10. So recent equipment purchases are still split between Windows 7 and Windows 10. When I can get away with it, I've been running Kubunto (sorry, not MacOS), as recovering from arbitrary Windows 10 updates wastes a lot of time.

That said, I believe that just using Windows accounts to regulate access to the software makes the most sense. That was my original suggestion to the users, you've convinced me I should try harder to push that solution.

If that is not considered acceptable, my problem was that I was thinking of generating and storing encrypted passwords, but wasn't sure how to keep the file/database of stored encrypted passwords safe. An authentication server seems right.  Now I have a direction, Google might be my friend again!

Thanks.

[Stephan van Hulst]

Jon Swanson wrote:stored encrypted passwords

Statements like this should give you a knee jerk reaction. If you REALLY want to store keys use a key store. Otherwise, hash passwords instead of encrypting them.

[Jon Swanson]

My method of encryption was going to be to hash them and compare the hashed values for authentication. I was a bit loose with the terminology, sorry. I was mostly concerned with where to put them.

[salvin francis]

Something that is encrypted can be decrypted to get its real value
A Hash is one-sided activity. i.e. If you have a hash value, you cannot (ideally) get back the original value. That being said, a hash can be exploited using a "rainbow table". Which is a table of pre-calculated hashes of common passwords.
However, a strongly generated 'salt' can prevent this.

Hope that clears your doubts.

[Jon Swanson]

Thanks,

Yesterday I had said I was thinking of generating the password with PBKDF2 and Salt. So I believe I'm good on that part. I was really asking how to securely save and access the hash. It sounds like if I am going to implement my own security, I should be thinking about an authentication service.

[Stephan van Hulst]

PBKDF2 requires a salt (or IV) anyway, and if you don't specify one the Java implementation will generate a random one by default.

[Matt Wong]

maybe an addition to your own solution when windows-users isn't what you end up with: instead of making the whole application available to specific users or not, you still can limit write-access to an administrator

it sounds the workstations are in a windows domain anyway, or at least there has to be on centralized place where your 'user-file' is reachable from anyone want to use your application - so as anyone can read the file to determine if access should be granted to some credentials - you can simply restricted the write-access to only administrative users trusted to manage this user-file

it's just shifting what's available - but manage write-permissions is usually easier then overall access permissions

[Stephan van Hulst]

How is managing write access easier? And why would you permit any user to read all the keys?