Save Password-Button

[aignermax]

The Wallet has to be unlocked at every startup under Windows 10. In Linux it is not like this (?) Please add a "remember Password" to enhance the comfortability of this program

[avahowell]

This is intentional behavior. "Remembering" your passwords means writing it to disk in plaintext, which would allow malware or bad actors to trivially steal your wallet.

[DavidVorick]

Is it possible that the behavior seems different on Linux because siad is not being closed when the GUI is exiting?

[avahowell]

Yes, that is precisely why. This was fixed in https://github.com/NebulousLabs/Sia-UI/pull/386, but did not make the 1.0.2 release

[droghio]

This does bring up a good point, do we want siad to quit when Sia-UI closes? I see quite a few advantages if it does not:

• Users don't have to retype their passwords as often.
• They don't have to remember to relaunch Sia-UI every 3 months or so to renew contacts, their computer just needs to be on.
• Until we figure out the issue causing file corruption, limiting the quit/launch cycle could reduce the likelihood of the issue.
• Users won't have to wait for the block chain download every time they open Sia-UI.
• Hosts don't need to keep the UI open (which could be annoying).

For experienced users these things don't matter as much, but they could be the key factor in whether a new member sticks with the platform or not.

Also as for the issue of storing passwords on disk... right now given how long the passwords are I'd wager that 90%+ of users just copy the seed to a text file. We really aren't giving users any security advantage in that case, just shifting the blame.

[avahowell]

The decision we came to regarding siad and Sia-UI lifecycle coupling was to bind siad's lifetime to the lifetime of the UI (assuming Sia-UI started siad, which is the case in the vast majority of users), because users wouldn't have an easy way to quit Sia otherwise. That, however, doesn't mean that the UI has to quit when it closes. The behavior as it stands is to keep running in the tray and provide a tray menu to manage the lifecycle of siad. All of the advantages of keeping siad running apply, except users also have the ability to immediately show the UI or quit Sia from their system tray.

While most users are probably simply using a text file, we should try to do everything we can to encourage correct security practices. Implementing plaintext password storage into the app, even if optional, would be engineering insecurity into the platform.

@DavidVorick thoughts?

[aignermax]

Well I just think it should be there - even my online banking software saves the password for good reason.

What if there is really an attacker on my computer. If I enter my Password every time he can simply watch my keyboard (a keylogger is written with getasynckeystate in 10 minutes).

Also I think that almost all users use textfiles to store their password as you also mentioned, If I understood you right. In Addition I guess the password might be in plaintext in Memory on some Points, as I think there is no SecurityString used? [just guessing]

I am looking forward to a maybe weak AES encrypted and usable - password-saving mechanism.. How about Encrypting it with AES with a user-defined Password? then everyone can simply choose his/her own PW that he/she can remember what do you think?

[DavidVorick]

@ma68546 it's far, far more likely that the attacker gets a chance to scan your computer for password files than it is that they get a chance to install a keylogger onto your system. Furthermore, a keylogger requires analyzing the output and figuring out which blobs of text are passwords. Our passwords are particularly hard to find, because they are a bunch of dictionary words, and there aren't any 'warning triggers' that an attacker could use to realize that you've started a Sia instance (unless you are using the terminal).

A keyfile on the other hand, if we implemented one, would be programatically saved to disk. Most likely, we'd use a single file that always had the password in the same place, regardless of what machine you are on. That's really easy to scan automatically, and now an attack only needs to compromise your userspace filesystem instead of needing to compromise the admin account on your machine (keyloggers need admin access before they can be installed).

If a user is using their own text file to save their passwords, at least that text file is going to have a semi-random name and reside on a semi-random location on-disk.

I'm not sure how the UI handles remembering the password, but even if it is sitting in plaintext in memory, you still have to read application memory and know the layout of the Sia program in order to find it. Some operating systems will deliberately randomize the locations of objects in memory to make this harder (though I'm pretty sure if your OS was doing this you'd be aware of it - OpenBSD, FreeBSD, and hardened linux all have the ability to do this, but most people don't run any of those). More importantly though, you need admin access to a machine to read the memory of another program that's running.

The AES idea is basically just wrapping a stronger password with a weaker password, which doesn't really fit the spirit of protecting the user's funds. If the user doesn't want to remember the password themselves, they should really be using a secure password manager like KeePass. KeePass can remember your password, store it securely, and then has a master password that you use to protect everything.

@johnathanhowell I think it makes perfect sense to encourage sane password behavior in our users. We should not compromise on the fact that we don't save the password for the user, and we should not compromise on the password strength (well... if we can figure out a way to compress it to 16 bytes instead of 32, that'd be fine. And actually, I know just how to do that, while preserving compatibility. Heh. Use a 16 byte seed that you hash to get the 32 byte seed that the wallet expects. Problem solved.).

I think telling people to use a password manager to manage the somewhat-ungainly Sia password is the best option. It throws security to a system that's designed to do security well.

[aignermax]

@DavidVorick I really agree with you, that it is a super important task, to save the users data and his money aswell.

1. How did your first testusers react when you told them that they have to remember a 32 Byte password?
2. How about Programming a password Manager where the user can choose his own password let's say minimum 8 chars? I did this before, it is quite simple. Then you have a encrypted password and the attacker has to sniff your keyboard to get it. He will have root-access always if he is on your system already. Under Windwos he needs root access to search for a Password-Plaintext.txt file anyway.
3. You may agree, that our biggest goal is, to get all the normal users to use Sia. How about copying the success of other products? How about making sia as comfortable as the Mist wallet of ethereum? or like the Boxcryptor for Dropbox?

Let's Make this software work for the dummy User! for the Dropbox User! Let's make Sia Big!

What do you say?

[VoidingWarranties]

Hey @ma68546, thanks for your feedback!

To build off of what @DavidVorick and @johnathanhowell have said, it's also important to note that the password is the same as the wallet's seed in the UI. It is important to write down this seed somewhere safe so that your wallet is recoverable should you lose access to your machine. It is tempting to let users choose their own password, but decoupling the password and seed doesn't encourage the user to write down the seed. In fact we've already seen a large number of users click through the wallet creation steps without ever writing down the seed. I'm worried that adding a "remember password" button would only increase the number of users that click through without writing it down.

I do agree it is not convenient. There is a usability / security tradeoff and it is often difficult to find the right balance. I think Sia often leans towards security, but we'll continue trying to find the right balance.

[DavidVorick]

Decentralized systems operate in much more hostile environments than centralized systems like Dropbox. They are also more secure. But, if you forget your password, there's no reset button. You don't just lose your account, you lose all the money inside it too.

I am cautious to allow users to easily engage in activities that put them at high risk. Most users don't even realize that they are close to losing everything. We had dozens of miners exposing their wallet keys over the open Internet and it's hard to blame the victim.

It is okay if you want to make an alternate ui or wallet plugin. But I feel everything that comes out of Sia officially should weigh heavily on the side of security, because at our core that's what we are about.

[aignermax]

Dear @DavidVorick and @VoidingWarranties , thank you for the detailled Information and your patience, I really know about that issues and totally agree with you, that Sia must be safe. I think you also agree with me, that the seed must be safe. Storing the seed in plaintext seems to be unsafe, right? Have you tried the solution that Ethereum uses with the mist wallet? They encrypt the private keys with a master password. The user can choose that pw himself. So they are using a password manager. Here the solutions: C#: http://www.codeproject.com/Articles/15750/Simple-Password-Manager-Using-System-Security (about 80 LOC) C++: https://github.com/michalmuskala/pass_manager should not this be a good solution to our problem? also user defined pws are much more safe. Users can use upper and lower case, numbers and special characters! How about that system to at least ease the access ?

[DavidVorick]

also user defined pws are much more safe. Users can use upper and lower case, numbers and special characters!

The passwords generated by Sia are cryptographically as strong as you can get. The primary reason that we do the password generation for the user is because users have a strong track record of generating insecure passwords.

The passwords generated by Sia have 256 bits of entropy. A secure password only needs 128 bits, and the fact that we use 256 is actually a bug. Adding more numbers, special characters, length, etc. would certainly add more entropy, but the extra entropy is completely unnecessary. A 1024 bit password is equally strong to a 128 bit password - they are each essentially unbreakable.

[DavidVorick]

closing this for now, though acknowledging that there's a lot of user pressure for a user-settable password.