Everybody knows that you shouldn't keep sensitiveInfo variable at your js code. The better way is to put it inside local storage. Could you pls explain vulnerabilities of the first approach with help of my example?
Example:
You use bundler, which bundle all your js files together. sensitiveInfo isn't global, but stored inside YourStorage.js. To access file which keeps it you do:
import YourStorage from 'somepath/YourStorage';
YourStorage.sensitiveInfo = newValue; // QUESTION: can you steal this value? Is it accessible from console?
Questions:
Is sensitiveInfo variable accessible from console?
Could you please describe mechanism how someone can steal sensitiveInfo?
If someone can steal it from my code, why he couldn't from local storage?
UPDATE: (whom I'm trying to protect from?) I'm writing mobile web app, where users can spend real money. I want to protect them from all kinds of attack where they can loose their money (i.e. locally installed viruses)
Anything put in javaScript that is downloadable can be easily seen on the users device. The most common method of securing sensitive information that must be passed back and forth to a client is to:
First, use SSL to encrypt the information over the 'wire'.
Second, if the data is of a very sensitive nature - such as a token used to process credit card information (do not store the card number in this token!) - that data should be encrypted itself, using a seed/key that is securely stored on the application server.
Often you would write the application to require both the identify of the user AND the device be verified. After this verification, you would then decrypt the token - using a key stored only on, and only available from, the server-side of your application.
Using this practice you can reasonably assume the user and device are whom they say there are. Of course, such applications need proper authentication themselves - with said credentials not being stored on the device - to prevent stolen devices from easily being used to access the application account/data. Do not simply rely on a devices screen lock for security.
Related
My requirement is to store UUID-like on client's web browser to identify user's machine (web browser copy in this case). Let's say, if IT guy comes to fix a laptop of HR manager, they could easily view username/password saved in web browser and use that credential on his PC later. My idea is to simply save an UUID in web browser's local storage and send it to verify at backend server. If username or password or UUID does not match, deny access. The problem is local storage can be viewed and re-created by IT guy easily.
After Google, I believe that Web Cryto API is the way to go. It can be used to store encrypted object in IndexedDB with extracable = false, but can read via JavaScript, I hope. Unfortunately, most of online article are talking about encrypting/decrypting data which is too much for me. I just want to store data that can't be transferred to another machine easily, but can read with JavaScript. That's it.
Can anyone provide sample code or blog post to achieve this? Thank you.
PS 1) I know about web browser fingerprint concept, but it's not a solution since fingerprint value keeps changing from time to time.
PS 2) My JavaScript on production environment will be obfuscated and/or webpacked and/or made-confused by my own algorithm. Yes, it can be reverted-engineering by webapp developer, but not by most of users in the organization, I think.
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 am still new to Angular apps and wonder about some security concerns and would appreciate some tips on how to handle this.
Lets say I access my Amazon S3 Server from my Angular Application. That for I need to write somewhere my bucketname, accesskey and secret key... but since it is all visible to the user everybody can see the secret key which does not make him anymore secret of course.
I can also not use something like a SALT etc. to create user passwords for the same reason. All is visible in the end and even with minify and uglify anybody can reverse it as well.
What is the best approach to do things like this? So far I can only think of one thing and this is to not use javascript or angular at all in this cases and for example only access my S3 bucket via PHP. But this cant be the only way I hope?
For Firebase it looks the same problematic since everybody can see all infos right away and can connect basically to my DB and than add for example information he want to. Of course I can setup rules and make certain things obligated but this can be also sniffed out easy inside my code at the end which seems all pretty unsafe if I compare this to a php/mysql backend.
You can use the Cordova SecureStorage plugin to store access and/or session tokens:
https://github.com/Crypho/cordova-plugin-secure-storage
Since the Android implementation of this secure storage uses the KeyStore, the users must have a secure screen-lock set (like fingerprint, pattern or PIN). The plugin provides functions to check this, so you will be able to give a warning (or block login) if this is not the case. Without a locked screen there is no way to save your keys in a secure way on Android.
In web application , How secure is local storage in Html5 or else is there any other way to secure the sensitive data in local storage.
Project Structure:
Front End: Html5,Angular js, Middletier: Asp.net webApi , BackEnd :Sql Server.
Once user login into the page, that credentials is encrypted by using some cryptography algorithms.It will be stored in db.
After that every child action like products list, order details, book history ,add product need to validate that.
While refresh after the page, data gets lossed so need to persist the data so i have choose localstorage. stored the username and password encrypted using some js algorithms and in put in local storage.
I feel it as not safe , because of any one can steal the data from the browser tools.
Is there any alternative approach in this scenario or else this approach is secure.
can anyone help me to process.
There is something that every Webapp Craftsman must know:
There is no repository beyond your firewall that can be fully secure. Why? Because the open door that you NEED to allow your application manipulate the data is accessible to everyone.
Imagine that you decide to encrypt the content of the local storage.
This will prevent someone with access to the browser's local storage (e.g. the developer tool) to be able to read/write the data. But how your application will access the data? You have two options:
Send the encryption algorithm + passphrase within the client-side app. This will expose all your data if someone manage to read the code of your app and access to memory of the browser (e.g. the developer tool)
Send every data from the client-side to the server to be decrypted there. Well ... this is pointless. Is better to store the data in the server for that matter.
You can try as much as you want, you will need an open door, and that open door can be use by anyone.
But I've a question for you: Do you really need a fully secure repository in the client side? This kind of repository weren't created for be fully secure, but they are secure enough!
For example, the session cookie of your web app is stored by the browser right? And if someone steal that cookie, it can impersonate the user and your application will never notice it, right? This is pretty scary when you think about it.
Nowadays nobody put to much thinking on this because browsers are secure enough to protect cookies from malicious access. And of course, they did the same to protect the local local/session storage, IndexedDB, WebSQL, etc.
So, if your data is more precious than your user session, keep it in the server. If not, go ahead and put it in the browser.
PRO TIP: Consider encryption when storing in a no secure repository to make it harder to get. But remember that this comes at a price: you will not be able to use the query system of those repositories to search over encrypted data.
I'm building a web app that needs to work offline. The system is built to capture sales transactions. The bulk of the "offline" part is fairly straightforward -- I just need to store data locally and sync it when I'm back on the network. So far, so good.
The problem is with authentication. The app will run on a shared machine with a single OS user account. If I'm offline, how do I authenticate the user?
Users themselves do not have any private data that I will need to segregate (i.e., I don't have to protect them from each other on the client). I need to be able to validate their password so I can let different users login throughout the day even if the connection is down.
One approach I'm thinking of involves caching the password hashes on the client-side in an IndexedDB. Only a limited set of users will be allowed to log in from a specific shared machine, so I won't need to cache my whole password database locally. Assuming that I have a good password policy (complexity and expiry requirements) in place and the hashes themselves are secure (bcrypt), just how horrible of an idea is this?
Do I have any other options?
This is effectively how Windows (and other systems) work when the machine is not able to reach the domain controller (e.g., you take your work laptop onto the airplane and need to log into your laptop w/o connectivity). Your machine has written down a cache of your username|password pair and will let you in via those credentials even if it's offline.
I think generally speaking storing the username|password hashes is pretty safe, assuming you're hashing them reasonably (e.g., using a salt, using an IV, etc). One exposure you'll want to think through is having the hash file "escape." If this is sensitive data you'll want to be exceedingly careful -- and this may not even be acceptable, but if it's not super sensitive data then you're probably OK: with good hashing I think you should be reasonably (but certainly not completely) safe.
Maybe this is little unrelated, but I use this approach in my nodejs project.
When a user is authenticated by username and password, he/she is assigned a unique API key used only for this particular session.
Each user can have only one API key.
This API key is added to any request done to server, to authenticate the user.
When the user logs out, the API key is deleted. Also the API key can be purged on the server, that makes the user authenticate on the server one more time.
I can provide links to nodejs open source programs that use this approach if you interested.