2

I'm looking for ideas to authenticate a user without the usual trip to a server. Any semi-secure way of authenticating a user on the client side is acceptable.

I'm think of storing some encrypted secret in a js file, then only users that have the correct code will be able to decrypt it, and the correct code can be either entered or stored in a cookie or something. Sound good, or any other ideas?

cubitouch
  • 1,929
  • 15
  • 28
bmw0128
  • 13,470
  • 24
  • 68
  • 116
  • 9
    The problem with this is that the user can manipulate anything and everything client-side. It will never be safe to do client-side authentication. What happens if those cookies are stolen and put on another machine? – crush Jan 08 '14 at 20:07
  • 1
    Authentication without a server is easy. The question is "what are you going to do with such authentication". If you are going to let users to your server-side resources after authenticating them client-side, you're gonna have a bad time. – Wiktor Zychla Jan 08 '14 at 20:10
  • Any semi-competent coder will be able to get around any so-called "security" if you give the user the ability to authenticate solely on the client. If this not-really-security is good enough for your app, then it doesn't really matter how you do it. Best practices say "don't do this." If you are determined to go forward, then pick a way that gives you the sense of Good Enough that you feel is appropriate. – Katie Kilian Jan 08 '14 at 20:14
  • @CharlieKilian Right. He might as well paste it in red text in a box fixed to the middle of the page. ;) – crush Jan 08 '14 at 20:20
  • The real question is why force a user to authenticate at all if it's only semi-secure? – crush Jan 08 '14 at 20:27

3 Answers3

0

Maybe you can store a hash of a password and encrypt the sensible application JS source code, in order to evaluate it when the user is "authenticated" with the correct key ?

See this article about Google's method about javascript processing. Use an encrypted javascript string source code, and you are client-sided secure ?

cubitouch
  • 1,929
  • 15
  • 28
  • That is not secure in any way, shape, or form. The client can read and execute all of your Javascript, _by definition_. If you encrypt Javascript so that the client actually can't read it, it becomes impossible to execute and therefore useless. – SLaks Sep 03 '14 at 03:07
  • I never said that the javascript Will remain encrypted, Just That only a correct user key can decrypt it (see the technique in the article I mentionned). – cubitouch Sep 03 '14 at 06:50
  • You might as well use access control and not serve it at all to other users. – SLaks Sep 03 '14 at 12:18
  • I was answering this part of the question : "I'm think of storing some encrypted secret in a js file, then only users that have the correct code will be able to decrypt it".Never said that this was good practice... (or usefull at all) – cubitouch Sep 03 '14 at 15:29
0

Take a look at oauth by client side javascript. Search google for 'oauth client side only'.

For example, this - https://developers.google.com/accounts/docs/OAuth2UserAgent

vodolaz095
  • 6,680
  • 4
  • 27
  • 42
0

I'm think of storing some encrypted secret in a js file, then only users that have the correct code will be able to decrypt it, and the correct code can be either entered or stored in a cookie or something.

What you're asking for is definitely possible, but I'm not sure it will actually be useful to you.

You need to use a key-derivation function like PBDFK2 ("Password-Based Key Derivation Function 2"). The user enters a password, then the KDF transforms the password into a key. Then, you use the key to operate a strong symmetric cipher like AES (and make sure you use a secure mode of operation like CBC). This approach is reasonably secure, but it's still vulnerable to key loggers (OS-level and browser-level) and memory-state examination.

The important point here is that the user must enter a password in order to encrypt the secret in the first place. You can't send the user a secret and then demand a password. The user can use a password to encrypt a message and then have the system require that same password later for future access.

Alternatively, you could choose the password yourself, generate the key and encrypted data, and then send your chosen password (along with the encrypted data) to the user to remember or store securely.

Practically speaking, CryptoJS is a JavaScript implementation that supports both AES and PBKDF2.

apsillers
  • 112,806
  • 17
  • 235
  • 239