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.
Related
I want to use Stanford's implementation of AES here:
http://crypto.stanford.edu/sjcl/
However, it is essentially useless if I use it as they suggest
SJCL is easy to use: simply run sjcl.encrypt("password", "data") to
encrypt data, or sjcl.decrypt("password", "encrypted-data").
As anyone can simply load my site, look at the java script and use the password to decrypt the data the same way I would.
How do i make this solution useful?
With a bit more back-and-forth I think I understand what you want to know better enough to give you an answer. Let me know if this is what you were looking for.
In general, managing symmetric keys is very difficult. There are two primary uses for symmetric ciphers:
Protecting the privacy of stored data for later use by the same person. If you use an online backup service, you really hope that your data is encrypted on the client before being uploaded to the online service -- you do not want them to have access to your data in plaintext. But when you go to decrypt the data in the future, you're the one to supply the key. This means you could store the key on offline media (CD-R, USB memory stick, SD card, little notebook next to the monitor...) or online (browser cookie, OS-supplied keychain of some sort, or standard file...).
Protecting the privacy of data while in transit between two parties. One party encrypts the data and the other party decrypts the data. This is how spies communicate, how TLS provides HTTPS client-to-server security, how SSH provides client-to-server security. In this case, both parties need to agree to the key that will be used, and this can be done with Diffie-Hellman-Merkle Key Exchange or using a public-key encryption algorithm such as RSA to allow one party to encrypt a randomly-generated session key in a way that it can only be decrypted by the other party.
The library you have found looks like it is highly optimized for the first case -- allowing users to encrypt their data for you to store and then retrieve for them later. Because they use a password based key derivation function it is prepared to handle the poor passwords that are available through simply typing on a keyboard -- the function will allow building safer keys out of just what a human can (or will) type on a keyboard.
Of course, it could be used for the second case, but presumably you're using this in a browser that has full TLS support, which can provide for end-to-end security in case you choose to use both client certificates and server certificates.
If you chose to allow the user to store encrypted data through your software, you should definitely make clear where the decryption key is being stored. I could see a use case for having a cookie on the browser store the key -- so that the user does not need to re-type it when they want their data. But if they change machines or browsers, they'll need to know the password so they can again retrieve their data.
However, if a user thinks their data is "secure", perhaps they should re-type their key every time they want to use their data. That way, the user alone is responsible for the security of the key; browser flaws that allow exposure of cookie data -- or locally-running malicious code -- cannot simply read the key off disk.
The downside of all this, of course, is that there isn't an easy answer available: you have to decide between the simplicity of storing passwords or the safety of not storing passwords.
Cryptico seems like a super slick RSA encryption library.
cryptico.wwwtyro.net
In regards to JavaScript applications, suppose I want to send data to the client, have them do something to the data, and pass it back. How can I use RSA to ensure that the data clients send back to the server is not tampered with? Since JavaScript is easily reverse-engineered, is there any practical client-side application of cryptico?
Do you - by your example - mean that you want to hide from the user what his client is doing with the data? If so - it's impossible.
You should never trust any data which comes from the client.
If you send encrypted data to the client to process - you must assume that the user knows (or will know if he wants) the encryption key, otherwise it will be impossible to process. In other words there is no secure way to hide from the user what his client processes. Obfuscation - like you've noticed can always be cracked no matter what language you use.
I think that the most common and practical client-side application for this library would be encrypting user's data and sending them to server or vice-versa. There may be some cases you can't use SSL. Moreover, you can make -for example- an encrypted post on facebook which only your friend will be able to decrypt (because he knows the key).
There is a solution to what you seek (I'm sure there is more than one). My answer requires two non-conventional approaches to what we call a 'secure connection' and how you receive the 'client code'.
You need a physically pre-shared key that initiates a secure connection, and because it's pre-shared it doesn't have to be RSA, which then opens up speed opportunities and higher levels of encryption security for you.
Physically pre-share your client code in a similar manner, i.e., download the code from a cd in a magazine or from a pre-paid card sold in a market. This stops the MITM from sending you tampered and exploited clients, which ssl allows. Once client is known to be secure, and a real secure connection, mentioned in (1), is established, the client code can be updated.
With the combination of a pre-shared key that develops a secure connection and client code that can pass a checksum, you can achieve what you are after.
Ideally, we should have pre-shared secure connection keys available in the market now, but we don't. So, for you to do it alone, would require to implement something similar for you website specifically until people in this country get their act together with some real security. You would have to give them keys over your phone, through the mail, etc. And your client code would most likely have to be a browser extension to install it due to cross domain security issues.
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.
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)
How can a user, using one of the major modern browsers, know for sure that he is running my unmodified javascript code even over an untrusted network?
Here is some more info about my situation:
I have a web application that deals with private information.
The login process is an implementation of a password-authenticated key agreement in JavaScript. Basically during login, a shared secret key is established between the client and the server. Once the user logs in all communication with the server is encrypted using the shared key. The system must be safe against ACTIVE man-in-the-middle attacks.
Assuming that my implementation is correct and the user is smart enough not to fall victim to a phishing attack there remains just one large hole in the system: an attacker can tamper with my application as it is being downloaded and inject code that steals the password. Basically the entire system relies on the fact that the user can trust the code running on his machine.
I want something similar to signed applets but I would prefer a pure javascript solution, if possible.
Maybe I am misunderstanding your problem, but my first thought is to use SSL. It is designed to ensure that you're talking to the server you think you are, and that no one has modified the content midstream. You do not even have to trust the network in this case, because of the nature of SSL.
The good thing about this approach is that you can fairly easily drop it into your existing web application. In most cases, you can basically configure your HTTP server to use SSL, and change your http:// requests to https://.
This is an old, open question but the answers seemed to not do this justice.
https:// provides integrity, not true identification nor non-repudiation.
I direct you to http://www.matasano.com/articles/javascript-cryptography/
Don't do crypto in JS, because a malicious injected script can easily grab passwords or alter the library. SJCL is neat, but it offer a blatantly false sense of security (their quote, and quoted by above)
Unfortunately, this is not as great as in desktop applications
because it is not feasible to completely protect against code
injection, malicious servers and side-channel attacks.
The long-term issue is that JavaScript lacks:
Uniformly working const
The ability to make objects deeply const and not reprototypable.
Code-signing
// codesign: cert:(hex fingerprint) signature:(hex MAC)
Certs would be managed similar to CA certs. MAC would be used with appropriate sign/verify constructions.
Crypto, clipboard stuff are reasons to have JavaScript native plugins (signed, of course)
Getting JavaScript engines to all implement a standard is another thing, but it's doable an it's absolutely necessary to end a large swath of malware.
You could have an external Javascript file which takes an MD5 hash of your login JS, and sends an Ajax request to the server to verify that it is correct and up-to-date. Use basic security or encryption practices here - public/private keys or some other method to be sure that the response came from your server.
You can then confidently display to the user that the client-side scripts are verified, and allow the login script to proceed.