How effective is it to implement HMAC using JavaScript libraries like crypto-js ?
In the example provided in crypto-js website
[ https://code.google.com/p/crypto-js/#SHA-2 ] it is mentioned
var hash = CryptoJS.HmacSHA512("Message", "Secret Passphrase");
If the secret key is mentioned in the java script file itself ,any one can check the view source and know about the secret key.
Is my understanding correct ?
Also , please let me know when such crypto javascript libraries need to be used in web applications ?
Yes you are right. Here is the points:
Firstly
The work can be used server side, with node.js. So, no security issue about the secret key
Secondly
Client side, the security issue exists, but the HMAC-X functions are used to sign messages, so the normal workflow is to use the user secret passphrase to sign a message and then, send it on the network (the signed message, not the secret). The secret should be deleted when the job is done.
So the user can access to the secret by debugging the code, but it's his so... no really security issue in facts.
Related
I realize that there are other posts on Stack Overflow asking similar questions, and the answer is to NOT to store passwords in local storage, but I need to. If there is a better approach, please let me know.
I am building a password manager. I am trying to develop it to work mostly offline. The way it works is that the user stores their "vault" on my golang web server. The server is only ever accessed when the client or server needs to be updated. So: the user logs in, the vault is sent from the webserver to the client, each time a password entry (username, password, name, etc) is created, each aspect of the entry is encrypted using the user's "master password". Since I would like the webapp to be able to work offline, I need to store some version of this master password in local storage or as a cookie (preferably as a cookie). I would like it to work similarly to other password managers, so if anyone can provide some insight on how they approach this problem, please do.
What is the best way for me to store the master password locally? I would like my approach to be as secure as possible. If there is a different approach I can take, I would love to know. My main thing is that I need the webapp to be able to work offline.
Please note that I am not using node. If I can provide any additional information, please ask.
Thank you!
The best way is to (as everyone is saying) NOT save data locally. That is a huge security issue. Other thing is that a Website can not be offline (unless its a PWA), so running the website offline is never gonna happen (Unless you create a PWA).
My Suggestion is that if you want to make it work offline you can create Chrome extension and use chrome.storage API for storing Encrypted password ( storing plain password is not recommended ). Even with web extension, it is not advisable to store password locally.
You can make it work offline if user is logged in and but not connected to internet anymore and browser is still running. Every time user open browser after closing it, you should (always) authenticate user again.
1). Since you are encrypting vault using plain master password, you can use any encryption/decryption method to encrypt master password ( which will be stored using api ) and to decrypt the stored encrypted password ( decryption is required as you will need plain master password for verification ).
Hashing algorithm is not a good option here, since hashing is one way encryption and depending on which algorithm you use you can have different hashes for same string.
2). Yes, you can check storage.local browser compatibility here
Electron can help you to develop what you want. With Electron you can develop offline app's to any S.O.
And you only need to know about HTML, JavaScript and CSS.
Take a look at official website
Today a lot of apps are made using Electron, like VS Code, Slack and a bunch more, look at this link: App in Electron
And if you really want to test, do a simple app following this Tutorial.
To store your password locally you can do a encrypted key and concatenate the machine info to make part of the password.
For example:
You can get programmatically machine MAC Address +
And do a simple and less secure MD5 encryption, and you will get something like this: e99cde2308fb2ff5612f801c76b18f6c
In the world exists a lot of encryption manners.
Good luck.
I would need to encrypt the some content before saving it on local storage in html5 and JS, at the moment I use Stanford Javascript Crypto Library.
At the moment I use a code like this.
usernameEnc = sjcl.encrypt("password", username);
passwordEnc = sjcl.encrypt("password", password);
localStorage.username = usernameEnc;
localStorage.password = passwordEnc;
I am able to encrypt correctly. As I am building a HTML5 application with JS and the JS code is download in the client, how can I protect the PASSWORD for avoiding easily decrypt the script?
Maybe I miss the point I am little puzzled.
Unfortunately, there is no way for you to protect your key. It's JavaScript and it should somehow be downloaded to be executed in the browser. You can obfuscate the key to make it a little hard but someone with average knowledge would be able to break it.
What I would suggest doing is that you can encrypt the contents using the user's password. So every time the user should enter the password to decrypt the contents.
Don't use the users password just as it is. Use a key derivation function such as PBKDF2. There's a JavaScript implementation for PBKDF2 in the crypto-js library.
Anyway something that you ought to know is that if your application can read it in the client side, someone determined can read it too no matter how hard you try to protect it.
Users are sending messages to each other and publish private information for other users via rails app.
The goal is to secure the messages, so neither system admins, nor database leaks won't be able to compromise the data. Javascript client side encryption with recipient key, encrypted data is stored in the database and decrypted on recipient's side. Keys are not stored in the system.
Does is make sense? Is there a solution?
Thanks a lot!
Update: I mean asymmetric cryptography. Two keys for each user: one public for encryption, one private for decryption. And a password for the application itself. User logs in using his password, creates a message, which is encrypted client side with a recipients public key (stored in the system) and saved in the database. Recipient logs in using his password, then enters his private key to decode messages. Decryption is also client side, private key is not sent to the server.
Sure. Use this http://crypto.stanford.edu/sjcl/.
Especially look at the demo http://bitwiseshiftleft.github.com/sjcl/demo/
One thing to keep in mind, the only way for you to not store the keys is for the user's to derive them from a password ( which should not be the one they use for your site). This is fine and is what the above library does.However,if they forget the password, there is no helping them,
On the client side, you can use openpgp.js. It's legit easy to use lib for creating keys, signing, encryption/decryption, etc.
Might be one of the solutions.The jsbn library is a fast, portable implementation of large-number math in pure JavaScript, enabling public-key crypto and other applications on desktop and mobile browsers.
http://www-cs-students.stanford.edu/~tjw/jsbn/
RSA Cryptography Demo http://www-cs-students.stanford.edu/~tjw/jsbn/rsa2.html
I need to post a form to a secure server with a SHA-1 hash of: some of the form fields and a secret key.
I'll be using javascript to create the hash (with the help of http://crypto-js.googlecode.com/files/2.3.0-crypto-sha1.js), and put it in a hidden input field in the form. The recipient server will check the hash against the same key.
But where should I store the secret key? I can't put it in the javascript, as the page source could be viewed (even if obfuscated?).
My site is hosted on a UNIX server to which I have ftp and telnet access. I assume that if I put the key in a separate .js file on the server, that is equally insecure.
How else could I store it on my server in a way that is secure, but accessible only to the javascript on my page? Thank you.
What you want to do is impossible. You can't store or even so much as access a secret key in javascript without your users being able to see it as well. You have to create your hash on the server instead of on the clients computer.
Obfuscating your source would barely be a hindrance to someone trying to find your secret key, who knows a little bit about Javascript, and tools to tidy it up and such.
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!