I'm looking for a secure way to store FTP passwords in a database that are usable only by specific users. The FTP details should be stored in a way that if the entire database is exposed that the FTP password isn't exposed. This probably should rely on the user's password to temporarily unencrypted the FTP password only when the user prompts for a FTP action. I'm looking for a solution that could implement this. Probably useful to add it concerns a web based application using javascript and php.
This is not about how to use salt, hashes, md5, sha1 etc. This is about securing FTP passwords that the server should be able to use e.g. connect to a FTP server with. This is simply not possible with hashes because those are only one way. Some symmetric password method should be used.
Example use case:
User logs in to server
User tells server to download file from his FTP details stored securely on the server
Server looks up the FTP details and removes the encryption (possibly with the users password) This question is about how you implement this step effectively
Server does whatever it has to do and then removes the unencrypted password
You could use Mcrypt: http://php.net/manual/book.mcrypt.php
Edit: While the following no longer appears to apply to the question (which now seems to want to run an FTP action on account of a user (not connected via a universal authentication mechanism), which requires a reversible scheme), I am leaving it because I think it contains valuable information.
I recommend reading Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes.
It will likely answer a number of questions, including what salt is (how to prevent rainbow attacks), why MD5 isn't an ideal solution for a password hash (it's too fast and no longer requires a "significant crypto breakthrough"), what can happen if data is compromised (why plain-text is not stored), etc. It provides valuable insights.
I really like this quote:
No, really. Use someone else’s password system. Don’t build your own.
It's so true, even if tongue-in-cheek.
It sounds like what you are looking for is an MD5 hash.
http://en.wikipedia.org/wiki/MD5
They are frequently used when storing passwords into a database, for further security you might also want to look into salting the password as well.
http://en.wikipedia.org/wiki/Salt_(cryptography)
Related
I have an Electron Application that needs to connect to an external PouchDB / CouchDB and a FTP-Server to retrieve some data. So in my Code I use
remoteDB = new PouchDB('http://my-Couch-User:my-Couch-Password#123.456.789.225:5984/myDB');
ftp.connect({host: ServerIPAddress), user: 'my-FTP-user', password: 'my-FTP-Password'});
I'm not working with highly confidential data, but having my passwords for external servers disclosed in such an easy readable form gives me the goosebumps.
Does anybody have an Idea how to at least hide them a little bit? (I know there is no way of really securing them under JavaScript)
Consider storing the confidential data in environment variables and access them via process.env.FTP_USERNAME and process.env.FTP_PASSWORD, for example.
Passwords or tokens really shouldn't be hardcoded and readable.
If you have a lot of configuration values, credentials or tokens, then you can consider using dotenv (https://www.npmjs.com/package/dotenv) or something similar.
Edit
Now that we learned about the OP requirements with his comments below this answer...
It is not possible to hide passwords in any application. It will always be possible to extract them.
Consider changing the server side code so that your applications don't talk with the FTP server directly but with a proxy where credentials are not required. The proxy then talks to the FTP server and the credentials will not be exposed.
Consider using a system that provides access via tokens in addition to credentials. You could ask users to login with their personal credentials and the system could generate and send personal access tokens for the server.
if you don't want to have them on the code and you don't want users to login with their own credentials, then I can only think of either having them on a separate file that compiles the info or do a request to a server that generates session data for the app.
But people with a bit of knowledge would still have ways to get the info in both cases.
We are developing an application that requires serious security. Now, my problem is that client enters a password, and that password should be sent to another client in an email. The key point here is that even the server should not see the password, so the client must send the email directly to another client through the application using client-side stuff.
If you want to transfer the Data from one client to another by email you must go through a server. In this situation what I recommend is encoding the password with a key that only the clients have access to, thus making it unreadable to the server. Or having the key stored on a different server.
You will need an email server that you can install on the client.
There are several Python based email servers. FreeSMTP is easy to install and configure but is only free for 10 emails per day - but certainly easy to get going for proof of concept.
Finally you will need to talk to the email server from your client code. It is not clear from your question whether you client is Flex or JavaScript. If you are using Flex, then SMTPMailer might help. http://code.google.com/p/smtpmailer/. It might not be possible to do this with JavaScript - see Javascript IMAP and SMTP client?.
The concept doesn't seem to be a good one though. Instead can you send a non reversible hash derived from the password - then the server will never see the password - but the hash may still be useful for authentication purposes.
I'm looking for an implementation of crypt(3) in javascript. (Not a generic "crypt" algorithm, but the crypt(3) one used in /etc/shadow e.g. on Linux systems). Anybody seen one? With an open license?
I'm a little worried about performance too: Would it even be possible to write one in javascript? E.g. the sha512-crypt source has:
/* Repeatedly run the collected hash value through SHA512 to burn
CPU cycles. */
for (cnt = 0; cnt < rounds; ++cnt)
{ ... }
And so if the algorithm "burns CPU cycles" in C, what will it do in javascript? Fry? (E.g. in IE6? Yikes!) I'm not writing a brute-force attack util in javascript, just a crypt call once in a blue moon, so perhaps it'll be ok.
Background: We're looking to import users from a user-provided /etc/password//etc/shadow file for our webapp. Since the only information we have about the users' passwords would be in crypt(3) output format, then to avoid sending the users' passwords back in clear text, as far as I can see, we would need a client-side (javascript) implementation of crypt(3) so when the webserver provides a salt, the client sends back the crypt(3) output (appropriately hashed for security).
Any alternatives to using crypt(3) client side that allow us to safely authenticate server-side against /etc/password//etc/shadow and don't require https:// will also be considered valid answers.
Javascript cryptography isn't secure. You have to use SSL That link has a lot of good reasons why, so I'll post just one here:
If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.
If you send your Javascript crypto over SSL, you no longer need Javascript cryptography; you have "real" cryptography.
Additionally, since you're only sending the hash of the password and comparing it to a hash you have, it's trivial for an attacker to copy the hash and use it whenever they want. This is called a replay attack, and it's particularly insidious because you won't be able to tell anything wrong is happening.
Because of that, you have to use SSL. Have the user send their password over an SSL connection, and do the crypt(3) on the server. Depending on the web framework you're using, you can use a pre-existing module (such as Django's PAM backend, which doesn't quite do what you want but is a good starting reference) or roll your own implementation.
I'm currently developing an application in HTML+JS based almost entirely in ajax connections (using the jQuery.ajax() call to ease the process).
I was thinking about the best practice to make secure calls without using HTTPS (at least at this time. I can't afford paying for a certificate right now).
At this point, the only thing that concerns me is the registration and login steps. Maybe the login is a bit easier. I thought of sending the username and a timestamp, and then encrypt them using the user's password. So, by doing this, I wouldn't be sending any password (keeping as a secret like in OAuth). The server should check the user, decrypt using the password and pairing the recieved timestamp with the decrypted result. The server should keep the nonce-like number into a database (to avoid repetition attacks) and then give back to the user another unique id (encrypted with the user's password). At that point the user should start using that key to encrypt all his information (and probably another nonce) and send it to the server. Please correct me if you find any mistake or leak.
The very big problem to me is the registration. I can't encrypt with a regular password the information, because if I do that in the javascript, any could know the password. If I serve temporary generated passwords to encrypt and I send it from the server to the client, any sniffer could get it and use to decrypt the info.
I know HTTPS could save my life at this point (and maybe that's the only solution), but at this point I'm not able to use it.
Is there any other solution, or should I wait until I can use HTTPS? Bear in mind that if I could skip the wait, it would be better. Thanks mates!
Short answer: You can't do it without HTTPS
Longer answer: If you try to do it without HTTPS, you will find yourself trying to reproduce everything that HTTPS was designed to do. You could reach at some point, but it is unrealistic to believe that you will succeed in implementing even the 1% that HTTPS offers. The only benefit you will have would be an obscure security mechanism (security through obscurity), which may be OK for not critical systems, but would fail miserably in a real critical situation.
You could create your own certificate you know and then work with Ajax the same way as with regular HTTP calls. The only drawback is that the users will get a warning message.
Using an SSL Certificate is the only way really, if you encrypt it in javascript anyone can read the code and decrypt it.
http://www.startssl.com/
Generate a public/private key pair on the server, along with a randomly-generated salt.
Attach the key pair and salt to the user session object.
Send the public key and the salt to the client-side code.
Use the public key and salt to encrypt the AJAX requests.
This would not be a trivial task. You'll probably find that it's cheaper and more effective to just buy a certificate.
EDIT: This also means that all the regular HTTP traffic (HTML, images, CSS, etc) is sent in the clear. That could be a problem, since it might allow an eavesdropper to indirectly figure out what the user is doing.
I think you should have a look at :
http://assl.sullof.com/assl/
Here is the description of the project :
aSSL is a library distributed under MIT License thats implements a technology similar to SSL without HTTPS.
aSSL enables the client to negotiate a secret random 128-bit key with the server using the RSA algorithm. Once the connection has been established, the data will be sent and received using AES algorithm.
aSSL is composed of some Javascript files and a server side component. Because I have recently changed the negotiation algoritm from RC4 to RSA, only a pure Javascript (ASP) server component is currently available. I will do a porting for the main web languages (PHP, Java, Perl, Python, TKL, etc.) as soon as possible once the library has passed the beta phase.
Is there any way of authenticating a homepage using JavaScript? I do know a couple of ways but they are extremly easy to "hack" because the username and passwords are stored in the script itself - as arrays.
Do you guys know any good ways of authenticating just a single subpage or two?
No, there is absolutely no way to authenticate a user using pure JavaScript.
JavaScript is executed on the client side, and thus entirely and easily manipulable.
Authentication always needs to be done on server side. JavaScript can be used to send the credentials to the server, but never to check those credentials.
Ou yeah, there is a safe solution. It's called "challenge/response technique". It works like this:
server send to client a challenge (some random string)
client attach to received chalenge a password (from user input) and make hash of this combination
server do the same (challenge + password from DB) and verify equality
if everything is OK, server logins user to site
Safety is achieved by that mean, that server send every challenge only once! If anybody capture client's response, it is not adaptable, cos server never send this challenge again.
As long as the final decision on whether or not the user gets to see some content is done on the client, it will be pretty easy to hack.
The only way that could possibly work would be if you somehow encode the content with a password, so that the desired information is simply not accessible as long as the password is not know. But even that is probably easily brute-forced and it would be quite complicated to implement.
It is certainly possible: you can encrypt the web page and use javascript to decrypt it. It rarely makes sense to do that, though.
It's not possible. Any data sent to the client in an unauthorized session should be considered public. Any sensitive data (eg: passwords) sent to the client in an unauthorized session should be considered compromised. Any data received from the client should be considered untrustworthy.
You can only trust the server.
Of course, you could write your server-side code in JavaScript using nodeJS