Question

Is it kosher to render authentication credentials into a javascript SDK from server-side code?

For instance, in Django templating, it might look like:

<script type="text/javascript">
    sdk = Sdk();
    sdk_username = "{{ users_sdk_username }}";
    sdk_password = "{{ users_sdk_password }}";
    sdk.connect(sdk_username, sdk_password);
</script>

It feels a little bit sketchy, but I’m not sure how to authenticate the javascript SDK on the server and pass a token to the client.

The username and password are things the current user of the webpage should know anyways, but not something that should be generally public.

Answer 1

Really I think a more basic problem is that you’re storing passwords in a way that they can be recovered. For many years now, it’s been considered a much better practice to store a hash of the password, combined with a “salt” value.

The idea is that you:

1. Take the user password supplied when it’s established through some initial registration or a “change your password” facility, and add to it some number of random bytes (the “salt”);
2. Put the random bytes and the user password through a crytographically-secure hash function; check current literature to see what to use (SHA-1? I don’t know what’s the best as of now, Feb 2012). Then, store the hashed password plus the random “salt” bytes in the database. The salt bytes should be in plain text; their job is to make a “rainbow table” of zillions of possible passwords less practicable.
3. To check a user password when authenticating, prepend (or append, as appropriate) the user’s saved salt value (accessed by claimed user name) to the supplied alleged password, and apply the same hash function. If the hash result matches the stored hash, then the user has supplied the right password.

I’m not a cryptography expert, so I would encourage you (or anyone reading this) to do more research into latest techniques and best practices. For example, in recent years some interesting attacks against these schemes have been concocted, involving some timing of operations. Thus, it may be best now to make sure that your response to failed (and possibly successful!) passwords involve some random delay. Even that might be at issue if your attacker could (for a maybe wildly imaginative example) monitor power consumption of your servers! It’s a scary world.