I want integrate on-line payments with my web (html + jquery). Easiest way is just send form on specific link. One of parameters is signature. Signature is hash from from fields and private key. Problem is I don't wanna expose my private key in javascript code. Is any secure way to do it?
Here is test code for form:
http://developers.payu.com/en/restapi.html#creating_new_order_form
and signature generating algoritm:
http://developers.payu.com/en/restapi.html#references_form_signature
Short answer is... No. Well, maybe but not really.
You cannot do the whole process in Javascript securely as it requires you to load the key into the users browser. That's an instant security game over.
What you can do is have a server (key store) somewhere that holds your private key and encrypts messages on demand. That would prevent end users seeing your private key, but it just moves the problem down the line - how do you know that the browser making the request is a genuine user and not someone malicious? If you just sign anything you're presented, you may as well skip the security entirely. If you're going to have a server anyway, why not use it to serve the webpages and validate form data too?
So really, you need something server-side that validates user input, checks that it's sane/untampered and then signs the message and passes it on.
You have to ask yourself why you need to do this from within a browser... The whole point of signing a message is to prove who it comes from. If it's coming from someone else's browser and you know nothing about the message, why would you sign it as authentic and coming from you?
Related
How to hash/encrypt string value in JavaScript? I need a mechanism to do so for hiding some data in localStorage/cookie?
It is something related to security concern but I want some protection for my data.
There are lots of encryption libraries for javascript. Here's the first one that came up on Google: http://crypto.stanford.edu/sjcl/
Your user can always gain access to the key, so this won't protect data from your user. If you want to hide things from the user, you'll have to encrypt it on the server and never send the key to the client.
I wrote a simple demo html (SSL enabled) forms to access some university services thru it. It requires the user to login with his university ID first .
My question is , how to encrypt the logins data even from me the owner of this page ? Is it possible ? so that the user can confidently use this.
You could use HTTP Digest Authentication which does challenge-response authentication and always sends password hashed.
The problem with Digest is that UI for it is ugly and logging out is left up to the browser (you can't have a reliable logout link).
Alternatively you could implement your own challenge-response mechanism in JavaScript, e.g. http://code.google.com/p/crypto-js/
but it's rather pointless, because the user doesn't have any guarantee that you're doing it, and that you won't replace the secure script with an insecure one in the future. As the site owner (or somebody that hacks your site) you could change the script and "steal" passwords at any time.
SSL is good. That's the best real security you can do client-side.
You can ensure that you're storing passwords securely on server-side — hash it with a slow hash such as bcrypt (not md5/sha1) and use unique salt for every password.
Is there any way that i can (securely, base64 ruled out) encrypt data in javascript without using encryption keys. I know its unlikely, because my encryption engine would be available, but does anyone know of any method that can be used
EDIT:
Upon request, i am trying to hide data that a user entered into a textbox before it gets submitted. The data is completely random and the user will never be asked to write it again. Its not a password, its essentially like a post
No.
You need keys for encryption to be secure.
If you don't have keys then either nobody can unlock it or everybody can.
I think it would be more helpful if you explained what you were trying to accomplish. What are you trying to protect? Who are you trying to protect it from? Where are you sending the data?
If you are trying to hide something from the client, encrypting it on the clients machine means you would never be truly secure.
If you are trying to have the client send encrypted data to a server of yours, why not just use SSL? This is far easier.
Why not HTTPS?
What's the source of the data and where is it going? What's the difficulty of using keys? Again, why not HTTPS?
NEVER trust client-side data! ALWAYS presume can be deleted anytime and user can access and edit it anytime.
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
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.
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:
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.
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.
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.
Your JS source will be visible anyway and anyone can fake it easily. You have to do a server side validation
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.
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.
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.
I have a series of interlinked web pages, and I want to restrict access to these pages by asking the user to provide a login and password. However, my hosting account currently does not provide any facility for server side scripting - is there any way I can accomplish this objective using only client side scripts?
I was wondering how the following program works -
http://www.myzips.com/software/HTML-Password.phtml
Clarification: Thanks for your inputs. However, if I am configuring the web server, then is there a possibility of the user entering an username and password?
There is no way to create a secure clientside script. If the user has access to it, it's insecure.
If your host is running apache you can secure folders using .htaccess, on IIS you can do the same through directory security.
Below is a working solution to this problem that uses encryption, which I implemented myself.
A few users here have suggested using an encryption-based approach to client-side password protection. I needed this functionality too, so I implemented it myself. The password is hashed using PBKDF2 and then used to encrypt the page with AES256.
The tool is hosted here:
https://www.maxlaumeister.com/pagecrypt/
with source code available here:
https://github.com/MaxLaumeister/pagecrypt
Description of the project, from the project page:
PageCrypt - Password Protect HTML
This tool lets you securely password-protect an HTML file. Unlike other password-protection tools, this tool:
Has no server-side components (this tool and its password-protected pages run entirely in javascript).
Uses strong encryption, so the password-protection cannot be bypassed.
All you need to do is choose an HTML file and a password, and your page will be password-protected.
You can create a file .htaccess with something like this :
AuthUserFile path/to/password.txt
AuthGroupFile /dev/null
AuthName "Acces Restreint"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>
You then have to create the .htpasswd file.
It is possible to implement this, although you'd probably find it easier to simply switch to a different hosting provider. Here's how it's possible:
First, encrypt the entire body with a symmetric encryption algorithm and a random key (the master key). Store this ciphertext in a javascript block as text.
For all your users, generate a javascript hash mapping their username onto an encrypted copy of the master key (encrypted with each users key).
Finally, create a web page asking for username and password. Once they're entered, use the username to locate the encrypted master key. Decrypt that with the password the user typed in and use the resulting master key to unlock the original body. Use javascript to replace the existing html body with the decrypted one.
I don't know about client side scripts but you can use the web server to restrict access to your site.
In IIS you can use "directory security" tab settings: configure IIS Web site authentication
If there was one and only one password for EVERYbody, you could try a public key-type approach. You could provide a simple script for performing RSA decryption (you'd need to do the original encryption somewhere where you have access to some type of programming software). Then, you could supply the content as an encrypted string. You'd display a password box, the user would type the password,then the string would be decrypted according to the password. If the password is correct, the string will decrypt correctly, and the page will show. Otherwise, the page will look like a bunch of garbage. Be careful, though, because this client-side method would be very vulnerable to brute-force.
Sure, if security is not a big deal. Essentially, you will be putting up a door that says "Please don't come in if you don't know the password". Anything that does not use server-side technology is likely using JavaScript, along with a file in a protected directory to store the passwords. This is not password protection, however. JavaScript can be disabled, which will cause the page to load. No doubt, this will be countered by hiding the content...but the content will still be viewable through the source. There are a few other ways, but if you have content that is truly worth protecting with a password, this is not a good way to go.
Yes it is possible but it's not very pretty or even very good.
Your index page has an empty div where your restricted content will go.
On page load or a link being clicked, a prompt (window.prompt) asks for your password.
Your password is hashed and compared to a stored hash ( or array of hashes ) of the correct password in your script.
If you have a match you load the content into the div via AJAX
You could store the password in a cookie so it isn't prompted for each time ( not very secure but then this isn't a very secure system )
You're still not all that secure because the filenames of the pages you'll be loading will be visible in your script but it might keep a very casual surfer out.
You could obfusticate the urls thereby requiring some JavaScript knowledge to view. e.g rot13
You will need a JavaScript hashing script
Or you could use a cryptic html-filename as the password and ajax in / browse to that page if it exists :-)
Just as secure (or unsecure) as the other suggestions, but probably easier to implement.
You don't need public key for this - in fact public key decryption is limited to encrypting other symmetric keys and certificates in practice because its computationally very expensive. You just need a shared secret.
Encrypt the webpages using AES (for instance), using a key derived from the passphrase (by hashing). You then have to securely communicate the pass phrase to the user(s) and write some javascript to download the encrypted content, prompt for a passphrase, decrypt the data and incorporate it into the DOM.
Its all rather messy and very brittle - only one password for all users, as soon as its compromised you have to replace the stuff on the server and hope against hope that google hasn't cached it... Suggest you move to a real ISP
As to the HTML password program you refer to, there's no way to know its not snake-oil or broken... The phrase "best security with strong algorithms" is not exactly encouraging!