Password protected website with JavaScript

Question

I have a quetion which may be simple/dumb or not :). In other words I have no idea if is fair enough or a completely foolish idea. Just some free thoughts.

What if I make my login via JavaScript with pass in it (yes I know), but pass will be hased by Secure Hash Algorithm. For instance:

I generate a pass with SHA which looks like

var = 0xc1059ed8... //etc

and paste into the code. There will be also two functions. One will compare two values (given by me with user's) and second will generate sha form user's input.

Is this could be safe theoritically or this is a horrible pattern and stupid idea? Can JS handle it?

EDIT: I didn't mean serious autentication like banking one. Just when I have my pics and want only to a few ppl to watch them and 99,9% of ppl on earth can't watch them :) thx for responses

Answer 1

You cannot secure your site with Javascript alone. You will need some way to authenticate requests on the server.

Because all your javascript code is plainly visible to all consumers of your site. All a potential attacker would need to do is view souce of your website and they can bypass the password checking bit of your javascript and view the content behind it.

You need to have security implemented on the server-side, period the end. ASP.NET has a built-in way to do this called "Forms Authentication." Or you could use Session variables in a php script.

Answer 2

Sorry, no dice :) Secure authentication is not possible with client-side Javascript alone, because a positive authentication result could be faked. You will always need a server-side instance to authenticate against.

Answer 3

Since the hash will reside on the user's computer (in the browser), i'd say it's a terrible idea. It will be easy to manipulate it.

Answer 4

Your JS source will be visible anyway and anyone can fake it easily. You have to do a server side validation

Answer 5

You can use such a pattern to hide the password over a plaintext link and avoid https to login , but not as it stands.

The problem is that an attacker can steal the hashed password and use that to login to the server, and she does not need the real password.

This can be thwarted by a challenge response where the server sends with the page a "salt" : a big random number which is jumbled up with the password and then hashed, so the response is always different.

Unfortunately this has the effect that the server now needs to have plaintext passwords, which is a bad idea (ok, there are some tricks around this). So you might have to end up with a sending a salt, hashing your password, jumbling the hash with the salt by hashing it again and sending that to the server. The server hashes the stored hash of the password from the user db with the salt and compares both.

With security things get complicated real quickly and in complicated things opportunities lurk for the bad guys. A reason more to use well tested patterns, algorithms with a proven track record and libraries which have carefully implemented these.

And in any case it will be the server hwo has final say who can get access.

Answer 6

You'd be better off with no attempt at authentication at all -- at least that way you wouldn't give anybody the dangerous illusion that something involved might be secure.

Assuming you're dealing with a shared-secret situation, authentication is really pretty easy. You use a fairly simple challenge-response algorithm. Basically, the client sends a message to the server saying it wants to log in. The server responds by sending back a random number. The client encrypts that random number with the correct password, and sends it back. The server encrypts the random number itself, and compares the result to what the client sent. If they match, authentication has succeeded -- you've confirmed that the client has the right password.

The advantages of this: first, the password itself is never sent over the wire in any form, so an attacker has virtually no material to use in attempting to discover the password. Second, since the server generates a new random number for every login, an attacker cannot successfully authenticate by re-sending the packets it captured from a previous login.

Nearly any server with any sort of aspirations to security will already have something like this built in. It's purely a question of setting up your client to interact correctly with the form supported by the server(s) you care about.

Answer 7

The common answer is that 'no, you can't do client side authentication' and for conventional scenarios that is correct, but I can think of at least two ways to make it work:

1. Use the SHA password hash to redirect to a static HTML page (0xc1059ed8...html). As long as the virtual directory doesn't allow file listing, no one will be able to guess the name of the file you want to protect. This gets clumsy really fast though.

2. Use an implementation of an encryption algorithm (AES, etc) in Javascript to decrypt a block of text that makes up the actual content of your page. Really only practical for one highly valuable page though.

Server side authentication is really the best, but it is incorrect to say that client side can't be done.