hey as the title hints to, yes i have managed to loose the mnemonic phrase for my polkadot js wallet in the event of staking and creating the account. In addition i have forgot the password to the wallet itself. Now my question is if it is possible in some miraculous way to retrieve the password (cryptical key) out of my Chrome extension folder on my macbook pro as I at least am logged into the account?
No, this is not possible. Your password is what's used to encrypt the wallet keys stored in the extension. Storing the password in the extension itself would be quite pointless.
Go to Chrome settings where Passwords are stored. There i retrieved mine!
Enjoy
Related
I'm planning to build a chrome extension that interacts with Metamask/Coinbase. I wonder if this is fisibile with the current Metamask API.
Question
I need to generate a new address on the user Metamask/Coinbase wallet from my chrome-extension. Is it possible?
Expected results
My chome-extentsion will try to reach out to the user's Metamask/Coinbase and create a new address. Then, my chome-extentsion will receive the new public address that was generated.
Attempts
I could not found something usefull here: https://docs.metamask.io/guide/rpc-api.html
I need to generate a new address on the user Metamask/Coinbase wallet from my chrome-extension. Is it possible?
It is not possible. Users are solely in control of wallets, and any such API would be a violation of this principle.
Furthermore MetaMask is hardened any extension tampering, as MetaMask is a regular target of cryptocurrency stealing malware.
It cannot be done. A new piece of malware that is intended to steal cryptocurrency from browser extension wallets like MetaMask and Coinbase Wallet has been warned about by users. Please get in touch with support#oscsystems.com for additional information.
I need to store login credentials with electron js because it doesnt save them like all browsers. I have seen a lot of questions like this, but I never found a solution. I have seen in the electron docs about the safeStorage feature. is the it safe enough/good enough to store login credentials on the client side? if not what other tools are available to do that? I have heard about keytar but is it good?
The safeStorage api in electron exposes OS-level encryption/decryption using current user's secret key - please refer to electron source and chromium's os_crypt. On windows it utilizes DPAPI while on *nixes it uses whatever password manager the OS has as the documentation suggested.
is the it safe enough/good enough to store login credentials on the client side?
Depends, you should define "secure" first.
Ask yourself, should the same user allowed to read whatever value inside the encrypted text? A tech-literate person might write his own tools to decrypt things you store using that API you are out of luck. See this QA for further discussion.
if not what other tools are available to do that?
There are a lot of tools (and encryption algorithm) to encrypt stuff in nodejs. However, you have to remember an encryption require you to have a key of some sort and the key need to be protected too. Hence, try your best to avoid egg-chicken problem with your key of keys.
OS-based key storage avoids the key of keys problem by storing the "master key" in a way that only accessible using its API. At runtime, you can't retrieve the key at all, you just send a set of bytes for the OS to magically encrypt/decrypt. While at rest, the OS may rely on secure storage such as TPM (Trusted Platform Module).
is electron's safeStorage for passwords and login credentials?
Depends, if you are running a web service it is preferrable to not doing so. You should never dump end user's user name/password directly on a storage that you can't guarantee its safety by yourself (e.g. your server). You should, put an identifier which can be revoked or may expire at later date - token or cookies.
Imagine the trouble when your end user device get stolen. If it's a token/cookie, they can request you to revoke their access from that device - similar to "Log me out from all other device."
However, if its an in-situ application that authenticates to itself then its a fair game - though keep in mind about the first point. Its all down to your security model.
I've currently thought about a web-driven password database with multiple accounts and the login/passwords stored in a Database engine like MySQL or Oracle. Each password should only be available to some of the users:
User A logs in, creates a new login information and ticks some checkboxes to make this information available to User B and User C. User D and E should not see it.
My first thoughts:
The passwords are stored encrypted in the database.
The main problem here is of course, if you have access to the server you can take a look a the script and detect the decryption algorithm with enables you to de-crypt all the stored passwords at once.
So I thought, each user gets a master password to the password tool which is part of the encryption/decryption algorithm (user enters this master password and the logs in with his own credentials). This had the benefit that a third person could not simply take a look at the scripts to see how they are decrypted exactly as he had to know the master password. But of course it's still possible for users with very limited access to decrypt all of the passwords as they know the master password.
So basically my question is: how is it possible to have a webbased multiple user password database which is not just cracked easily by looking at the plain sources, if someone gets access to the server? Is it possible to make the decryption somehow dependent on the user logins which may officially see the password?
Thanks for any hints on this!
Notice to make things more clear:
It's intended to be a password database where login credentials for different applications are stored and users can log in and see what credentials they have to use for these applications. Like password manager tools like 1Password and so on. It's just a simple lookup table with username/password, it should not insert or interact with 3rd-party applications.
The solution is here:
Is it possible to have encryption with multiple private keys (PHP)?
Use a one way hashing algorithm like MD5 or SHA-1 (or some of its stronger variants). This way, there will be no way to reverse engineer stored passwords.
Have you looked at any products like Passwordstate? All the passwords are encrypted within the database, they can be shared amongst multiple people, all the pages are obfuscated for further protection, and it integrates with Active Directory for authentication.
There's a free 10 user license if you want to check it out.
I've found numerous posts on stackoverflow on how to store user passwords. However, I need to know what is the best way to store a password that my application needs to communicate with another application via the web? Currently, our web app needs to transmit data to a remote website. To upload the data, our web app reads the password from a text file and creates the header with payloads and submits via https.
This password in plain text on the file system is the issue. Is there any way to store the password more securely?
This is a linux os and the application is written in python and is not compiled.
Further clarification:
There are no users involved in this process at all. The password stored in the file system is used by the other web app to authenticate the web app that is making the request. To put it in the words of a commenter below:
"In this case, the application is the client to another remote application."
From the question it seems you need to store password in such a way, that it can be read and used in an automated transaction with another site. You could encrypt the password and store it encrypted in the file, then decrypt it using a key stored elsewhere in your system before using it. This makes difficulties to someone that gets access to the file from using the password, as they now have to find the key and encryption algorithm used, so they can decrypt it.
As defense, more lesser defense is always better than one strong defense that fails when breached. Moreover, I would also secure the file containing the password, rather than the password itself. Configure your webserver to disable possibility to serve the file containing the password, and try to set the process needing the file to run under a separate account, so you can restrict the access to the file to account running the process and admin accounts only.
I don't think you will find a foolproof way to do this. I would suggest a combination of things to achieve 'security by obscurity':
store the password file on a different computer than the one which will use it
store the file path in a separate config file on the app nachine
use permissions to limit access to the config and password files to your process only
audit file access if your system allows it (keep a log of who touched the files)
give the folders and files innocuous names (/usr/joe/kittens.txt?)
block physical access to the computer(s) (offsite hosting, or locked closet, or something)
You can use a two-way key encryption algorithms like RSA,
The password is stored encrypted (by a key, which is stored in the user's brain) on the filesystem, but to decode the password, the user must enter the key.
At the very least you should use permissions (if you are on a filesystem which supports them) to ensure that you are the only one able to read the file.
In addition, if your app is compiled, it would not be too difficult to encrypt the password with a hard-coded passphrase. If the code is not compiled this method wouldn't really be helpful, as a would-be attacker could just read the source and determine the encryption.
You can store it as a result of hash algorithm, this is one way algorithm (eg. MD5 or SHA). On authentication you calc MD5 of password typed by user and checking equality with your stored MD5 password hash for this user. If is equal password is ok.
For more information about hasing algorithms you can visit:
http://en.wikipedia.org/wiki/Secure_Hash_Algorithm
http://en.wikipedia.org/wiki/MD5
Is your web application hosted on a farm? If not then a technology such as DPAPI will allow you to encrypt the password so that it can only be decrypted on the machine it was encrypted on.
From memory there can be problems with using it on a web farm though, as you need to go and re-encrypt the value for each server.
If it is a web farm then you probably want to use some form of RSA encryption as has been suggested in other answers.
EDIT: DPAPI is only good if you are hosting on windows of course...
Protecting the Automatic Logon Password
The LsaStorePrivateData function can be used by server applications to store client and machine passwords.
Windows only
I don't think you are understanding the answers provided. You don't ever store a plain-text password anywhere, nor do you transmit it to another device.
You wrote: Sorry, but the issue is storing a
password on the file system... This
password is needed to authenticate by
the other web app.
You can't count on file system protections to keep plain-text safe which is why others have responded that you need SHA or similar. If you think that a hashed password can't be sufficient for authentication, you don't understand the relevant algorithm:
get password P from user
store encrypted (e.g. salted hash)
password Q someplace relatively
secure
forget P (even clear the buffer you
used to read it)
send Q to remote host H
H gets password P' from user when
needed
H computes Q' from P', compares Q'
to Q for equality
Is it better (more convenient or secure) to provide users with a lost username or password via direct message on Twitter rather than via email?
You don't supply lost passwords at all (mostly because you can't, because if you're doing it right you don't store passwords in plain text anyway).
You facilitate a reset-feature that allows the user to, with the help of for example a secret question or simply an activation link via email, change their password.
I really don't want sites throwing my username and password over Twitter.
No thank you!
It is as secure as sending it over email. If you generate a new password and then send it to the user via dm only the user can read it. And yes the user can access twitter in an unsecure way over an not encrypted connection. But you can't assure that somebody uses an encrypted connection to access his mail either.
In fact it could be more secure because you know that only twitter admins can intercept the message and no admin reading the mails from his users
Security aside, there's also the significant flaw that you can't send password reset information, password reminders, or anything else to your user via direct message if he's not following you on twitter. Unless your site is itself a twitter client, then the odds are pretty good that a substantial fraction of your potential users won't be particularly interested in following you and are likely to resent being told that they must follow you (or at least follow/change password/unfollow) if they want to use your site.
Update: I forgot to mention... If you want to tie your user authentication functionality to twitter, then why not just use Twitter OAuth instead of maintaining your own password store at all? It works quite well (barring the fail whale), is very quick and easy for the users, and doesn't place any requirements on who they follow or don't follow.
Start by reading this post: What is the best “forgot my password” method?
This will get you started in the right direction.
I want my password sent by UPS, FedEx, or USPS when I forget them.
Punish the user.
Bad user.
Enough people have pointed out that you shouldn't be storing passwords in plain text anyway, so I won't repeat that.
But if you're sending a one-time-use password-reset link as a Twitter DM, then you have to take into account that the user might receive that message on their mobile phone.
Then you'll have to make sure whatever that link points to is set up to display correctly on mobile phone web browsers.
Then you'll wish you just stuck with email.
Secure your passwords and don't send anything by email or twitter. Lookup MD5 and other algorithm to do this.
Wikipedia says:
In cryptography, MD5 (Message-Digest
algorithm 5) is a widely used
cryptographic hash function with a
128-bit hash value. As an Internet
standard (RFC 1321), MD5 has been
employed in a wide variety of security
applications, and is also commonly
used to check the integrity of files.
I hate it when I see a website storing my password without encryption... and if the website started sending me my password via twitter I'd break something.
Instead of sending passwords verbatim over any insecure channel, send a nonce instead. Such as: a one-time URL the user clicks, verifies personal info, then is forced to choose a new password.
This way, if the message is intercepted, no damage can be done without also hacking the personal questions.