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.
Related
I want to encrypt my API data so that the user can't see it in the network tab or as plaintext in something like the window.__nuxt__ object.
The way I'm doing this now:
encrypt data in back-end with a secret string (like a password)
send encrypted data to front-end
decrypt it on client-side (using the same password as in the back-end)
Here is the problem: The function that decrypts my data can be found by looking through the bundled JavaScript files in the Browser.
Although the function is obfuscated, it is possible the reverse engineer it. And since the password is stored within the function (it has to be, right? Since I don't have the process.env variables on the client-side) everyone can(theoretically) scrape my data.
What is the best way to prevent this?
I know that the data is visible eventually in the browser. I just don't want it the be visible in plaintext.
I'm using express in the back-end and NuxtJS in the front-end by the way.
There's no way to prevent this. All you can do is make it more difficult.
Ultimately, if the data is visible to the user in the browser, you can just get it from the DOM in memory. All the code to transform the encrypted data into the original information must be supplied if you need the user to see the data.
You can obfuscate the code, but your attacker doesn't even need to reverse engineer it to get the data, they just need to run it.
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.
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.
I'm writing an Chrome extension right now which autofills credentials similar to Chrome's autofill (in which case Chrome's autofill fails).
Is there a secure way to store the username/password in localstorage (all client-side)? If I encrypt the password, won't the key be locally stored as well effectively making the encryption useless?
Effectively, I want the user's credentials to be as secure as they would be if Chrome itself was storing the credentials in its password manager.
EDIT: is storing the encrypted password in localstorage and the key in a text file within the extension directory a safe idea?
This is a lightning-rod issue. See http://blog.elliottkember.com/chromes-insane-password-security-strategy for more. The position most consistent with Chrome's would be to encourage your users to use whole-disk encryption and to lock their screen when away from a logged-in machine. It's difficult for userland code like an extension (or a browser, for that matter) to properly implement secure storage, where "properly" means "resistant to a password-recovery utility that anyone can download from the internet."
You should file a feature request. It might be possible to expose a system-level API that does provide similar security to the underlying OS's keychain.
If I encrypt the password, won't the key be locally stored as well effectively making the encryption useless?
Yes, it would and yes, all client-side "encryption" is visible to the user or anyone who has access to the machine and therefore pretty much useless. Except perhaps for the purpose of obfuscation -- anyone with a copy of your hard drive won't immediately be able to tell the password in plain text. This may or may not be an advantage, f.ex. if using device-specific data to generate a key for encryption such as hardware UIDs, someone who gets the encrypted data won't be able to decode it right away without knowing the UID. Generally though you'd assume someone with access to the "encrypted" password would also have access to the machine in some way so all in all, again, user-side encryption doesn't really make a lot of sense when performed in the browser.
As far as i know, local storage is not a secure place for storing the password, or other sensitive details. Check out the link below, one of the person has commented of using the javascript 64 bit encoding and deocding scheme but i dont how far that method will prove to be useful for what you are trying to achieve.
https://getsatisfaction.com/apperyio/topics/how_to_save_account_password_securely_on_local_storage
Hope this helps!
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!