I have some sensitive information (my database username/password and cookie encryption key) in my config file for my Dancer application that I would rather not be shown as plain text in case someone does gain access to it. What's the best way to encrypt the file so it's not just text? Or is there a more secure approach that makes more sense than encryption (like restricting file permissions)?
Because you can't encrypt the config, as in the comment above says #ThisSuitIsBlackNot, but sometmes is good to hide passwords (e.g. hide the passowrds form some co-workers who doesn't knows perl - but has access to config files)
I'm using an combination of
security by obscurity
and fooling
In my config files are passwords in encrypted form, and looks like as instructions for configuration. If someone grabs/reads only the config file - get nothing usable.
Usually I'm using something like the next:
db.password: enter some safe password here such De4w.Quafy3yq
and in the code i exracting the "De4w.Quafy3yq" part and using rot13 or crypt etc... get the real passwd: "Qr4j.Dhnsl3ld". Or using the mh5 hash of a string as a password, or similar - simple algorithms.
It is simple, and effective against non-programmers - of course, isn't helps when someone knows perl and grabs the code too.
EDIT
Because seems (downvotes) than here are still some people who didn't understand what this mean, THIS ISN'T ANY REAL SECURITY. It is an nice (funny) method (of course unsecure - read again, it isn't mean any real security) how to hide the password form coworkers, who didn't knows perl. DON'T USE IT for any real password protection. OMG...
Related
I wonder if it is possible to have an easy authentication method that is restful, fast and provides a litte security.
SSL is not an option, because I can't rely on a valid SSL Certificate on the server of clients. Also HMAC is not really possible because the body of the request should be signed, when used properly, but in my case that body could be a large file. Further should the authentication be possible with JavaScript/AJAX.
I thought about something really simple. What's the problem with that one:
HEADER: X-Authentication: timestamp:username:sha256(timestamp:password)
The server knows the users password and could check the hash, the timestamp is used to only allow request that took place e.g. 10 seconds before. The replay window would be extremly small, and there are no sessions on the serverside.
If the hash is cracked the attacker knows the password and has unlimited access.
Alternative would be to use
HEADER: X-Authentication: timestamp:username:HMAC(password, 'timestamp+request-method+verb')
What's the way to go? I'm not a security pro, maybe storing the session on the server would be better (but not RESTful)?
I built a random hash algorithm that does what you need, it's called jAuthenticate.
You can download it from: https://github.com/thomasoeser/jAuthenticate
You can see how it works here: http://furiousgryphon.com/jauthenticatedemo.html
The reason it's a strong algorithm (in my opinion) is that I'm using a random number to influence the hash but I'm sending an obfuscated number with the hash.
Each hash is single use only.
Have a look, it's free open source (MIT).
HTTP authentication is extensible so you can invent your own mechanism (obviously at your own risk!). See https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p7-auth-20 for details.
Don't bother inventing your own new X- header. Using the existing Authorization header with your scheme is a better option.
e.g.
Authorization: kruemel-auth timestamp:HMAC(password, 'timestamp+request-method+verb')
Ideally new schemes will be registered with IANA along with a specification. A registry is being setup to track auth schemes that have been developed. See http://tools.ietf.org/id/draft-ietf-httpbis-authscheme-registrations-03.html
I am using the request module in the Firefox Add-on SDK to access my Perl application. In the Firefox panel the user will enter his name and password which is relayed to my Perl CGI application.
Firstly, I would like to know if this is a safe approach.
Secondly, is there any chance of encrypting the data and then decrypting it again on the server side (written in Perl using the CGI module)?
Firstly, I would like to know if this is a safe approach.
As far as the client-side goes - depends on how you store this password. If you remember the password rather than requiring the user to enter it again each time then you should use Login Manager for that (which stores it encrypted if the user defined a master password). When using Add-on SDK you will need chrome authority for that:
var {Cc, Ci, components} = require("chrome");
You can then replace Components.classes in the examples by Cc, Components.interfaces by Ci and Components.Constructor by components.Constructor and these code snippets should work correctly in your extension.
Secondly, is there any chance of encrypting the data and then decrypting it again on the server side
If your goal is to protect against eavesdropping then you do not want to use symmetrical encryption - it uses the same key for encryption and decryption and the key used for encryption will be visible to anybody looking at the source code of your extension. So you want to use an asymmetric (public-key) encryption algorithm like RSA. However, using it "manually" in Firefox is currently very complicated and involves accessing the NSS library via js-ctypes (DOMCrypt extension does it this way). Not to mention that you would still have to think about replay attacks and such. The much simpler solution would be using an HTTPS connection to communicate with the server.
If I have an app that connects to Amazon's S3 service, is it worth my time to hide/obfuscate the connection strings and API keys? I'm guessing that most hackers won't care all that much, but it would be financially painful if someone found this information and was able to upload data to my account!
For instance, if I store a username/password (or Twitter/Facebook API key and secret), these may be easily found using "strings". A hacker could see the functionality, grab the secrets and use them for nefarious purposes. I've seen people suggest using a simple Rot13, or storing the strings backwards or something like that in the app binary. Are these useful?
Has anyone done this or have any ideas/patterns/code to share?
-dan
You can hide your secrets in a webserver you have full control over, and then having this server relay the query to Amazon. You can then use whatever encryption/validation method you like, since you are not relying on what is supported by Amazon.
Once you have validated that the request is from your own application, you then rewrite the query including your secrets and then forward this to Amazon. The result from Amazon could then be relayed directly back to the application.
In php this could for instance be done using something similar to this snippet (not showing your url rewrite):
$fp = fopen($amazon_url,'r',false);
fpassthru($fp);
fclose($fp);
You dont really need to hide them...what you should do is have an extra key such as a secret, that one IS hidden and is only present in the signature of the call (which can be an MD5 hash or sha (or whatever)) without that secret key people wont be able to just make calls since the signatures created by the server and the offender wont match since they dont know the secret key used...
I'm guessing that most hackers won't
care all that much
It just takes one who's bored enough.
Has anyone done this or have any
ideas/patterns/code to share?
This is what SSL is for. You can encrypt all your transmissions or just the login process (which would return a session id that can be used for subsequent requests during the session).
Here is what I got for a webapp login scheme.
Present in database would be two salts and hmac(hmac(password, salt1), salt2).
When the user go on the login page, he gets salt1.
If he has javascript activated, instead of sending the plaintext password, it would send hmac(password, salt1).
If he does not have javascript, the plaintext password is sent.
So, on the serverside, when getting a login request, we'd first check what is sent (passwordSent) against hmac(passwordSent, salt2). If it does not work, we'd try hmac(hmac(passwordSent, salt1), salt2).
Someone getting access to the database should not be able to login with the password hashes and I don't think (but I may be wrong) that multiples hmacs diminish the hash resistance.
Do any good crypto expert see any obvious error I may have done ?
This looks a little like security through obscurity, what is the point of using javascript to hash the password on the client side if you still accept plain text password from the client?
You didn't mention if this was over https, if you aren't using https then you may as well have no passwords at all. If you aren't running https then any MITM can see the salt you are sending as well as the javascript used to hash the original password so you have nothing gained.
As for your concern about the possibility of hmac collisions between two salts, that is probably very unlikely (depending on your hash algorithm) and how secure you keep your salt values. Even with MD5 that has had some collision attacks discovered and has a set of rainbow tables, you will be ok if you keep your salt very very safe.
Please, everybody, please stop trying
to implement custom crypto systems
unless you have a background in
cryptography. You will screw it up.
--Aaronaught
Well said!
Sounds pretty far-fetched to me. If the objective of this is to prevent a "man-in-the-middle" attack by virtue of the plaintext password being sent over HTTP, then use SSL.
Hashing on the client side accomplishes nothing; unless the salt is actually a nonce/OTP, and not stored in the database, then a man in the middle can simply look at the hash sent by the original client and pass that along to the server. The server won't know the difference.
If this is supposed to make it harder to crack if someone gets hold of the database, it won't. If the hashing function is cheap, like MD5, this won't be any more difficult to crack than one salt and one hash (in fact it's actually weaker, since hashing is a lossy function). And if you use a strong hashing function like bcrypt, it's already good enough.
Please, everybody, please stop trying to implement custom crypto systems unless you have a background in cryptography. You will screw it up.
Probably obvious to you already, but you're effectively letting people log in with two different passwords in that setup.
If you want to give people the option of sending their passwords with encryption, I wouldn't tie that to anything strictly client-side, and just force HTTPS, as Harley already implied.
You might want to look at HTTP Digest authentication. That is a standardized protocol which avoid clear text password in any case.
I am working on Perl script that uses Expect to login via telnet to remote machines (don't ask, gotta use telnet). I also do perforce p4 login operations as necessary and use expect to pipe in the correct passwords. For now I just read passwords from clear text environment variable, i.e. export PASSWORD=password, which I know is no good security wise.
What's the best way to store passwords for scripts like these that need a lot of passwords for multiple systems? Encrypted in a text file somehow? Or something else?
Keep in mind I can't easily change the existing systems, like for example I can't really install SSH or anything like that.
Probably your best way is to put the passwords in a separate file, and lock the security for that file down so only you have read access. Unfortunately, if you store an encrypted password in your script, you'll also have to store the decryption method, so an attacker can run the decryption and recover your password.
There was a very similar question earlier, see my answer to it.
In short, a human has to kick off the chain of trust. Everything else is obfuscation.
Why worry about the passwords in the script if you're using telnet? A presumptive attacker is going to find it as easy or easier to capture the data off the wire than off the remote machine, and there really isn't anything you could do about it in any case.
This sounds like a case of trying to put bars in the window and leaving the door swinging open.
Since you're already using expect, you should look into being able to redirect a gpg -d on an encrypted file that contains your passwords. Storing passwords in a system environment variable is just plain wrong. The password that would be used to decrypt the gpg file would be entered on start then load all passwords from the file and run your stuff. Then you're done, so the passwords only exist in plaintext while the application is running.
Edit just as a side note, putting any passwords in a script is badness; remember that the script is just a plaintext file which makes seeing that password easy as anything. Likewise even applications that you compile can be reversed with "strings" which can look for strings that are contained in the code (usually passwords).
On the off chance that you're using Mac OS X, I found this nifty way to grab usernames and passwords from your Keychain.
Update: The link seems to be broken as of July 22, 2013. The following bash code snippet shows how I use the technique (to download iTunes sales data):
domain="itunesconnect.apple.com"
user="user#example.com"
pass=$(security find-internet-password -ws $domain -a $user)
I like the solution mentioned already of putting passwords in a separate file. In addition you could hash the actual passwords, much like whats done in /etc/passwd. Although you might use the same hash key for all of them depending on how your application. Obviously the drawback to this is someone has to enter the hashkey in order to run your script and thats not gonna work in a batch environment.
One place to start learning something about hashing is from this stackoverflow question