I started to create a Perforce wrapper for the Origen revision control module. I don't see anything about how username and passwords are handled. I know there is an existing User solution which can take care of passing in the username but what about the password?
thx
There is currently no support for securely asking the user for their password and then storing it locally within Origen, though I would like to see this added in future.
We currently use our own in-house solution, which just boils down to extending the User class from Origen to add a password method.
We typically reference this when making calls to some 3rd party API services, e.g. my_service.lookup(:blah, user: User.current.id, password: User.current.password)
If the password is not present, then it will prompt the user to enter it on the command line and it will then store it locally for next time so that the user does not have to continually enter it.
We encrypt the password (really just to avoid storing it in plain text, it could be de-crypted by anyone who has the responsible Origen source code to see the algorithm) and then store it in the user's home directory. The file is then made read only by the user which is the real protection from access by a 3rd party.
As I was writing this, I just remembered that we already have an open ticket for this, but no progress on it yet: https://github.com/Origen-SDK/origen/issues/97
Related
I want to build a command-line application using Go or Node.js. I want to make it multiuser, so a login feature is needed. I can implement the login feature but I don't understand where should I store the user data which can be fetched any moment at runtime.
The user data is needed to check if a user is logged in or not if he is logged in which user it is.
Need help with a method to store user data to check logged in status
Edit:
I had thought of this- If the config file is present that the user is logged in else not. Then I realized that if one tampers the file, the whole point of login feature will get invalid. I am guessing there must be a better way to do it, which I am trying to know by asking here
Many cli utilities opt to store their configuration as a plain text file on the user's home directory.
You can use any of the available configuration formats such as JSON, TOML, etc.
Although it's good to mention that this is not a secure way of storing data and if users should not be able to see others information in any way this is not the preferred way.
How much of a security issue would it be to store temporary / machine generated passwords as clear text in a database?
I understand that passwords should be encrypted using a 1-way hash function with salt. This is especially true for user supplied passwords as users typically re-use them over and over again. If the database was stolen, a thief might be able to gain access to user user accounts on 3rd party websites such as: utility bills, social networks, even potential for online banking.
How much of an issue would it be to store temporary/machine generated "welcome" or "reset" passwords as clear text in a database? The password would be emailed to users and must be changed upon login. The passwords that they supply would then be hashed.
The reason for me asking is that there are a some nice properties to storing a temporary password as clear text. For example, if a user does not get the "welcome" or "reset" email, an admin can quickly look-up their temporary password.
Because the temporary password would be machine generated, if the database was stolen, the thief would not be able to access any 3rd party websites that the users log into. The thief would however be able to login to the application that generated the temporary passwords.
Assigning these passwords a small "expiration" would limit exposure, but overall I am just looking to see how dangerous this approach would be.
You should not store even machine generated passwords in plain text.
Let's see what an attacker can do, if he somehow gains only read access to your database with SQL-injection (i made a small demo how easy SQL-injection can be, just click the next-arrow to get a malicious input).
The attacker with read access, could demand a password reset for any e-mail address he likes. Because he can see the new generated token in the database, he could call the reset page with this token and therefore can change the password of this user. Unnecessary to say, that he can now impersonate the original user.
Handle the token just like every other password, even if it can not be used on other sites. The data accessible by the user-account could contain other data (like birthday, real name), that can be used to hack other sites.
You absolutely must not store passwords in a database at all, let alone in plain text. You should store hashes of them. See this answer for why. Then you need to build all your password-reset facilities around that fact. See also this answer about password reset features.
I've currently thought about a web-driven password database with multiple accounts and the login/passwords stored in a Database engine like MySQL or Oracle. Each password should only be available to some of the users:
User A logs in, creates a new login information and ticks some checkboxes to make this information available to User B and User C. User D and E should not see it.
My first thoughts:
The passwords are stored encrypted in the database.
The main problem here is of course, if you have access to the server you can take a look a the script and detect the decryption algorithm with enables you to de-crypt all the stored passwords at once.
So I thought, each user gets a master password to the password tool which is part of the encryption/decryption algorithm (user enters this master password and the logs in with his own credentials). This had the benefit that a third person could not simply take a look at the scripts to see how they are decrypted exactly as he had to know the master password. But of course it's still possible for users with very limited access to decrypt all of the passwords as they know the master password.
So basically my question is: how is it possible to have a webbased multiple user password database which is not just cracked easily by looking at the plain sources, if someone gets access to the server? Is it possible to make the decryption somehow dependent on the user logins which may officially see the password?
Thanks for any hints on this!
Notice to make things more clear:
It's intended to be a password database where login credentials for different applications are stored and users can log in and see what credentials they have to use for these applications. Like password manager tools like 1Password and so on. It's just a simple lookup table with username/password, it should not insert or interact with 3rd-party applications.
The solution is here:
Is it possible to have encryption with multiple private keys (PHP)?
Use a one way hashing algorithm like MD5 or SHA-1 (or some of its stronger variants). This way, there will be no way to reverse engineer stored passwords.
Have you looked at any products like Passwordstate? All the passwords are encrypted within the database, they can be shared amongst multiple people, all the pages are obfuscated for further protection, and it integrates with Active Directory for authentication.
There's a free 10 user license if you want to check it out.
I've found numerous posts on stackoverflow on how to store user passwords. However, I need to know what is the best way to store a password that my application needs to communicate with another application via the web? Currently, our web app needs to transmit data to a remote website. To upload the data, our web app reads the password from a text file and creates the header with payloads and submits via https.
This password in plain text on the file system is the issue. Is there any way to store the password more securely?
This is a linux os and the application is written in python and is not compiled.
Further clarification:
There are no users involved in this process at all. The password stored in the file system is used by the other web app to authenticate the web app that is making the request. To put it in the words of a commenter below:
"In this case, the application is the client to another remote application."
From the question it seems you need to store password in such a way, that it can be read and used in an automated transaction with another site. You could encrypt the password and store it encrypted in the file, then decrypt it using a key stored elsewhere in your system before using it. This makes difficulties to someone that gets access to the file from using the password, as they now have to find the key and encryption algorithm used, so they can decrypt it.
As defense, more lesser defense is always better than one strong defense that fails when breached. Moreover, I would also secure the file containing the password, rather than the password itself. Configure your webserver to disable possibility to serve the file containing the password, and try to set the process needing the file to run under a separate account, so you can restrict the access to the file to account running the process and admin accounts only.
I don't think you will find a foolproof way to do this. I would suggest a combination of things to achieve 'security by obscurity':
store the password file on a different computer than the one which will use it
store the file path in a separate config file on the app nachine
use permissions to limit access to the config and password files to your process only
audit file access if your system allows it (keep a log of who touched the files)
give the folders and files innocuous names (/usr/joe/kittens.txt?)
block physical access to the computer(s) (offsite hosting, or locked closet, or something)
You can use a two-way key encryption algorithms like RSA,
The password is stored encrypted (by a key, which is stored in the user's brain) on the filesystem, but to decode the password, the user must enter the key.
At the very least you should use permissions (if you are on a filesystem which supports them) to ensure that you are the only one able to read the file.
In addition, if your app is compiled, it would not be too difficult to encrypt the password with a hard-coded passphrase. If the code is not compiled this method wouldn't really be helpful, as a would-be attacker could just read the source and determine the encryption.
You can store it as a result of hash algorithm, this is one way algorithm (eg. MD5 or SHA). On authentication you calc MD5 of password typed by user and checking equality with your stored MD5 password hash for this user. If is equal password is ok.
For more information about hasing algorithms you can visit:
http://en.wikipedia.org/wiki/Secure_Hash_Algorithm
http://en.wikipedia.org/wiki/MD5
Is your web application hosted on a farm? If not then a technology such as DPAPI will allow you to encrypt the password so that it can only be decrypted on the machine it was encrypted on.
From memory there can be problems with using it on a web farm though, as you need to go and re-encrypt the value for each server.
If it is a web farm then you probably want to use some form of RSA encryption as has been suggested in other answers.
EDIT: DPAPI is only good if you are hosting on windows of course...
Protecting the Automatic Logon Password
The LsaStorePrivateData function can be used by server applications to store client and machine passwords.
Windows only
I don't think you are understanding the answers provided. You don't ever store a plain-text password anywhere, nor do you transmit it to another device.
You wrote: Sorry, but the issue is storing a
password on the file system... This
password is needed to authenticate by
the other web app.
You can't count on file system protections to keep plain-text safe which is why others have responded that you need SHA or similar. If you think that a hashed password can't be sufficient for authentication, you don't understand the relevant algorithm:
get password P from user
store encrypted (e.g. salted hash)
password Q someplace relatively
secure
forget P (even clear the buffer you
used to read it)
send Q to remote host H
H gets password P' from user when
needed
H computes Q' from P', compares Q'
to Q for equality
Comcast has changed their login process so it happens in two steps. Instead of two input boxes for username and password, you submit your username first. Then on a second page you enter your password.
https://www.comcast.com/Customers/CustomerCentral.cspx
Due to some recent security
improvements, we now require you to
enter your user name and password in
two separate steps.
What could the security improvement possibly be in this system? If anything it seems less secure since you can confirm the existence of a username independently from it's password.
Any ideas on what they're accomplishing here?
My guess would be that they are targetting specific phishing/keylogging software which is "used to" finding all the login information on the same page. It's making the job of some malicious software a little harder.
If you use the "automatically fill in my forms" feature of many browsers, this will also separate the login information into two separate entries in the browser's data store, again making things just a little harder for any software which might try to exploit this feature.
Not sure if Comcast is doing the same thing, but I know a lot of bank websites I use lately started doing the following:
Prompt you for your username
Look up an image and a string that you specified at your account creation.
Display that image + string along with the password box.
The stated goal is so that, if you as a user notice that the image and string don't match what you picked when you created the account, you get suspicious and don't enter your password.
What is the benefit here? I don't see any either, as an attacker's script can just look up the image and string from the real login page. Maybe it makes dumb people feel more safe.
It is strange, on the password page they require your email and password, not the user name.
The user name is not a secret, as you use it in your mail address probably....
They still allow you to "stay signed in" ...
So Actually, I don't think there is a real security benefit
You can get directly to the 2nd login page if you bookmark it....
Simply so when you login to more secure areas of my account, you need to reenter your password instead of use the remember-me function, so if someone gets on the computer, all they can do is access email from a normal session. Yahoo does this also.