Home/ Questions/Q 7562533
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T13:25:50+00:00

I’m looking for an implementation of crypt(3) in javascript. (Not a generic crypt algorithm,

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0