I have a shell script which has password in clear text used in a command :
--username = 'USER'
--password ='abc100'
I dont want the password to be in clear text here in shell script. Is there a way i can keep this shell script password protected or to not pass the password in clear text and refer another file which is password protected ?
To solve this question well, it's really important to know how what this password represents and what sort of risks compromising it entails. It's also important to understand who has access to the machine on which this script and password file are stored, how the machines are set up, who needs to run this script, etc. It's really hard to give a good answer without understanding the full requirements and risks.
Assuming that compromising this password could have seriously negative repercussions and assuming that lots of people who should not have this password need to run this script, it would -- in my view -- be a mistake to store this password on the machines of everyone who needs to run this. You may want to consider having a smaller number of machines with much more limited access store this password and offer the functionality of the script through a webservice that uses an authentication mechanism such as OAuth (with Bearer tokens for automated access). Then the question becomes how do individual users have a script access the Bearer tokens needed to invoke the web service; although the Bearer tokens are also sensitive, they would at least be unique per user (giving a way to better detect compromise and abuse, though that is something you would still need to implement). In that sense, the question becomes similar to the original question, but with lower stakes.
Assuming that we are now talking about storing Bearer tokens, how you store it will depend on how many different users can access the same machine / filer system. For example, if many different people can have root access on the same machine, there is very little you can do. If there is one user per machine, however, and only that machine's owner can gain root, then you can use UNIX permissions to help limit / control access to files. For example, you could create a user+group that is dedicated to this specific script, have the script always run with that permission (e.g. via the sticky bit), and have the Bearer token information stored in a way that is readable only to that user/group (as a way to prevent other programs run by the same user from accessing that credential). In a setup where many people use the same machine but the people who can run as root can be trusted, you might just store the credential in a folder in the user's home directory that is accessible to only that user (and not readable/writable by the same group or other users); however, this does risk other programs run by that user reading the data. You could attempt to have the script encrypt/decrypt the content of the file on disk (e.g. embedding the key to encrypt/decrypt the data within the script), though unless the script were highly obfuscated and was regularly updated with this key rotated, that would do very little. You could also impose a short expiration on the bearer token so that the token need to be refreshed often as a mitigation measure to other programs misusing the token after it is no longer being used.
Related
Attention: Please read this topic carefully: This question is not seeking recommendations for books, tools, software libraries, and more. Instead, I am seeking for a method behind existing crypto in applications. A similar previous question got locked - IMHO due to a misunderstanding.
I am looking for the method (and maybe an implementation hint) how others obviously safe password on user drives in a safe way. For example on Windows: You can easily store the passwords of RemoteDesktop sessions w/o the need of entering a password when re-opening the session (even after re-starting your PC). Similar is the case for SMB connections or connections to SharePoint drives. My assumption is therefore, that there must be a safe way to safe passwords. This is what I want to understand. There are (closed source) tools around that store the password in some kind of hash in a file - which only works on that particular computer. This is what I am looking for but hopefully without the need to use excessive crypto libraries.
The background is that I am developing a native cross-platform app (esp. not a web-app but C++) that requires the input of a user name and password to connect to a proxy server. For convenience I want to store this sensitive information encrypted in the settings file of the app, which has INI-File format. Therefore, the file itself shall not be encrypted.
Does someone know an easy algorithm or method to do so?
I did find and tried algorithms based on SHA hashes and so one but they all either required a master password (which doesn't help because the point is exactly not to enter a password) or they literally used tons of crypto-libraries and non-cross-platform APIs which makes it hard to come to a cross-platform implementation.
All of these capabilities ultimately depend on a randomly generated master password that can only be read by a specific logged in user.
The safe way to store such a password is to encrypt it with a password that is generated from a hash of the user's login credentials.
If the user has multiple ways to log in, then a different copy of the master password must be stored for each login method, encrypted with a password generated from a hash of whatever credentials the user must supply for that particular login method. This generally requires OS support.
Often, implementations don't explicitly bother with this, instead relying on file system security to ensure that only the desired user can read the master password. In that case, though, you need to use disk encryption if you want to prevent the password from being accessed by super users or other means of bypassing file system security.
The disk encryption, though, will have its own master password encrypted with a login credential hash.
In Unix, when doing some action on behalf of some user, a system program usually calls seteuid(UID) (with accompanying setegid()) to switch to that user first, perform the action, and on finish switch back to superuser using seteuid(0). I time seteuid() and it's in the order of one to several microseconds (meaning, it's quite cheap relative to the action that needs to be done like manipulating files or running a CGI program).
I'm not familiar with Windows API. Do we do the same thing on Windows (but using ImpersonateLoggedOnUser() + RevertToSelf() API functions)? In general, how fast are these functions?
It is mostly the same, but there is one important difference to keep in mind : the Windows API you mentionned require a HANDLE to a valid token.
In other words, even running as SYSTEM (or any process that has SeTcbPrivilege), you need to impersonnate a logged on user.
The user can be logged on many ways :
Interactive with at a physical computer
Through a Remote Desktop Session
Pretty much any Microsoft network connections like file shares, name pipes, mailslots, RPC and all the others built on top.
Creating a process will make it inherit the current token in most cases.
It does not matter whether you used Kerberos, NTLM or maybe HTTP BASIC auth in IIS. It's all authenticated by Windows, so you get a token. On the other hand, an HTTP BASIC authentication in Tomcat will not give you a Windows token, so impersonation is out of reach.
Now with the tricky part.
When you think about it, a token is really just a memory structure with access control lists for authorisation (DACL) and auditing (SACL). It is created by an Authentication Package (AP). It is the AP that creates the token. And somewhat like a PAM in Unix, an AP can be replaced by custom code.
As a matter of fact, an open source setuid Authentication Package exist. Folks who ported CVS to Windows NT did the work of writing an AP that creates a token out of thin air, as long as your have the SeTcbPrivilege (root equivalent). I have never tried it, but it could give a token on the local machine for a user that is absent. The code is rather old (it will only create elevated tokens) but besides that, it LGTM. There is no authentication, no password or smart card involved, so a process running with that made up token will not be able to use it to authenticate to another computer.
To conclude :
The general idea is the same
If you play by the rules, you will only be able to impersonate a logged on user, regardless of the login procedure or location
You can change that behavior, but it
Impersonation is probably just as fast in Unix and Windows, as the inner workings are roughly similar. Chances are you will not notice the difference.
A suggestion : my copy of Programming Windows Security is all yellow from coffee, with post-it notes hanging out and torn pages. The best text ever on the subject, a must read if you want to understand Windows security.
I have a Matlab GUI used on my institution with multiple users. We store the application on a local server that everybody has access to. Now I want to add user information, last server, last database and etc.
My first idea is to create a .mat file, store the data under a structure and use the computer name/id as the handle. Requesting users to login is not a very good option since I have no clue how to store the passwords in Matlab (if you know how, please do tell).
I've been putting this on hold for a while now since I'm never quite satisfied with my approach. I would love to get some input (ideas) on this.
We have a similar situation, for a very small user base, we don't need any privacy (we only store window size and locations and few configuration parameters) so we store these are local mat files under users home directory (in windows I guess we store them in My Documents\Matlab).
So if privacy is not an issue you can just use user names without passwords.
I do NOT recommend storing passwords using matlab because it is not just a matter of storing hashed passwords but also you need to enforce permissions on a server (that you said is accessible to all of your users) which is in the best case senario a reinvention of the wheel.
You didn't say if these settings are computer specific, or user specific, or both.
If I built an application that accessed some of the data from say Gmail, Twitter and Facebook, and I want the user to be able to only have to enter their authentication info once, and it's reset after some days or weeks, what is the best way to do this, dynamically, in Ruby?
I see a lot of people just having a config file of their clients'/users' credentials like so:
gmail_account:
username: myClient
password: myClientsPassword
This seems a) like it's very insecure, and b) it wouldn't work if I wanted to store this kind of information for thousands of users. What is the recommended way to do this?
I would like to be able to build an interface on top of these services, so having to enter credentials every time the user made a transaction isn't feasible.
If you're comforatable with the potential liability when a hacker gets into your database / filesystem, then go for it. And in all fairness, you should also disclose to your users that their passwords will be stored on your system, and let them decide if they want to give your program that level of trust.
But why do this in the first place? Facebook Connect and Twitter & Google using OAuth there's no need for you to store user passwords at all. At some point a user's cookies will expire (or they'll try to access your site from another computer) and they'll have to re-authenticate. You can't prevent re-authentication - instead, you should make it as easy for the end user to handle as possible.
Such services are providing OpenAuth authorization. You are strongly recommended to have a look at it.
Security
I assume your application needs to know the password in plaintext. Then there is no way around storing it in some kind of plain way.
Store in some kind of encoded way eg. Base64, this protects you from knowing password when looking through the database with your eyes, but it does not protect you from anything else.
Ensure that the files are not readable from any other user
Encrypt your harddrive, so nobody can get the passwords from stealing your harddrive. Your computer will require inputung you the password during booting.
Storing
There is nothing wrong with storing much data in your filesystem. For better performance you can do the following
One file for each user, so the filesystem and not ruby needs to search for the data
Make a lot of subdirectorys. Some filessystems performance suffer's if you put to many files into one directory. eg. put the file 'abcd' into 'a/b/c/d'
You could use a database instead of the filesystem
This is the way it works for instance for fetcmailrc which has to be chmod to 600 (readeable and writable only by his owner). And yes, it contains the plain password.
I would strongly suggest you to use OAuth, but if you have to store the passwords (please be absolutely sure that you need to do it) you could use the OpenSSL library to encrypt the passwords. The OpenSSL library is quite poorly documented in Ruby, but as far as I know they are quite similar to the C OpenSSL library. Since I think you should use OAuth, and not storing the passwords I'll let you find the documentation yourself.
However, for the OAuth approach, you want to take a look at the OAuth gem. Google, Twitter (which I recommend you to use the excellent twitter gem for) and facebook (which has two seemingly good alternatives: RFacebook and facebooker)
I was thinking of making a small tool. It is not important what the tool will do. The important thing, is that the tool will need to store some sensitive information on the user's HDD. EDIT: The information that will be stored is USER'S information - I'm not trying to protect my own content, that I distribute with the app.
I understand that I need to encrypt this information. But then, where do I safely store the encryption password? It's some sort of an infinite recursion...
So, is there a way, to encrypt information on windows, and have windows securely manage the passwords? When I say windows I mean Windows XP SP2 or later.
I should also note, that users on the same system must not have access to other users information (even when they are both running my application).
I'm looking for both - .NET 2.0 (C#) and native (C/C++) solutions to this problem.
is there a way, to encrypt information on windows, and have windows securely manage the passwords?
CryptProtectData: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
Using from .NET: http://msdn.microsoft.com/en-us/library/aa302402.aspx
Historically, Protected Storage (available in XP, read-only in vista+): http://msdn.microsoft.com/en-us/library/bb432403%28VS.85%29.aspx
You should consider using DPAPI for this purpose. It will encrypt your data with a special (internal) symmetric key which is on per-user basis. You don't even need to ask for passwords in this case, because different users on the system will have different keys assigned to them.
The downside of it might be that you can't recover the data if the user is deleted/Windows reinstalled (I believe that this is the case, not quite sure though). In that case encrypt the data with a "self-generated" key derived from the password and store the password in registry/file encrypted using DPAPI.
You can use the native encryption facility. Set the encrypt attribute on your folder or file (from the property page, click on the "advanced" button). Then you can set the users that can access the file (by default this only includes the file creator). The big advantage of this solution is that it is totally transparent from the application and the users points of view.
To do it programmatically: using the Win32 API, call EncryptFile() on the directory where you want to store your sensitive per-user data. From now on all newly created files within this dir will be encrypted and only readable by their creator (that would be the current user of your app). Alternatively you can use the FILE_ATTRIBUTE_ENCRYPTED flag on individual files at creation time. You can check encryption info from the explorer on the file's property page, and see that app-created files are correctly encrypted and restricted to their respective users. There is no password to store or use, everything is transparent.
If you want to hide data from all users then you can create a special app-specific user and impersonate it from your app. This, along with ACLs, is the blessed technique on Windows for system services.
You might want to look at Isolated Storage, which is a way of storing settings and other data on a per-application data automatically.
See an example and MSDN.
This is an alternative to storing normal settings in the registry, a better one in a lot of cases... I'm not sure how the data is stored to file however so you'd need to check, you wouldn't want it to be accessible, even encrypted, to other users. From memory only the app. that created the storage can open it - but that needs checking.
Edit:
From memory when I last used this, a good approach is to write a "Setting" class which handles all the settings etc. in your app. This class then has the equivalent of Serialize and DeSerialize methods which allow it to write all its data to an IsolatedStorage file, or load them back again.
The extra advantage of implementing it in this way is you can use attributes to mark up bits of the source and can then use a Property Grid to quickly give you user-edit control of settings (the Property Grid manipulates class properties at runtime using reflection).
I recommend you look at the Enterprise Library Cryptography Application Block. Check this blog post. Windows has a built in Data Protection API for encrypting data, but the Crypto Application Block makes it more straightforward.
Um, what you're trying to achieve is exactly what DRM tried to achieve. Encrypt something then give the user the keys (however obfuscated) and the crypto. They did it with DVDs. They did it with Blu-Ray. They did it with iTunes.
What you are proposing to do will never be secure. Your average lay person will probably not figure it out, but any sufficiently motivated attacker will work it out and discover the keys, the algorithm and decrypt the data.
If all you're doing is encrypting user data then ask the user for their password. If you're trying to protect your internal data from the user running the application you're S.O.L.
Erm hash the password? You don't need to store the real deal anywhere on the machine just a hashed password (possibly salted too). Then when the user enters their password you perform the same operation on that and compare it to the hashed one you've stored on disk.