What a weird argument you make. So when the user gets infected with malware and leaks the 512 char long password that was forced on them he also gets to blame safe network?
The truth is actually the other way round. Safe should allow the user total and full control of their own security while taking full responsibility. Safe’s responsibility is to ensure the network side stays safe. If there is no technical restriction a password of one character should be permitted. Just make sure the GUI makes a warning that cannot be ignored if it thinks the password is insecure.
The best way i have seen yet is what many Linux installers do for root passwords: warn if it is too short while entering it, if the user clicks next it popups a warning it is too short. Then if the user knows it they can click next again (while nothing on the GUI has changed) and it will continue. This way you must know that instead of getting the warning popup again, this time it actually allows you to continue. Very unlikely to happen by accident, but if you “do the research” you find this unadvertised feature.
The credentials are used to address and decrypt the block that stores the user’s account information, so it can be argued there is a technical need to enforce a minimum level for at least the “account secret”, if not the password.
I do like that.
In the alpha, there is a mandatory password complexity though, and I can’t argue against that too much, either. They are using zxcvbn, which can verify the complexity much better, so you’re not restricted to one annoyingly specific idea of the “secure password”.
I may add that, as the project is open source, nothing can stop you from disabling the checks, as all of them are done (and can only be done) on the client side.
Actually, the argument he makes just highlights how people will react to news of breaches. Yes, it’s irrational. Yes, it would still do damage.
$60 million was stolen from Bitfinex. What does it say about bitcoin itself? Nothing. Yet the price plummeted, because hoomans are not rational. Only cats are jk
I don’t believe it is a technical necessity you describe but an arbitarily forced requirement.
I also don’t believe the bitcoin price drop following the hack was irrational. When you know the hacker will probably try and take advantage of the stolen coins you can assume the price will drop if/when he manages to sell them. So you may logically try to sell first (at least a fraction of your holdings).
If everybody tries to be called Jim, Sam, Tom on the network, we will have a few pretty hot blocks. I’m not saying it would kill the network, but it is something to think about.
But the hacker also knows that people think that’s what he would do, so they would sell, so the price would go down, so … why sell? No, he would probably opt to not do it exactly because he knows people are irrational. In fact, those who knew that the hacker would not (yet) sell because he knows it’s not the optimal time would also not sell. However, if enough people are on this side, that would make selling on the hacker’s part a good idea!
I’m not even sure rational/irrational are sufficient label for this It’s a GAME.
This problem has been studied and experimented on, by the way.
Instead of 2 passwords, why not one password and a security question? A lot of other websites use those. You could provide a few answers to random questions at account opening and one gets chosen randomly for you when you log in.
Also, why not have the user themselves decide how much security they want? We are discussing a centrally planned one-size-fits-all security solution instead of giving the individual users freedom over their own environment.
Lots of points in this thread. Just wanted to say, if the current way Launcher works sticks around in any capacity in the future, then I think the literal “password” should be first, and the “pet name” (“account secret”) second. I ended up typing my password in the first field accidentally, because I thought “account secret” was just some silly made up phrase that actually meant “password”. Then I get asked to enter my actual/real password lol. It’s just a user experience kind of thing. Obviously everything’s still in testing stages, but I think my idea (password first, secret second) can eventually work.
The network has no way to present those questions to you, nor do anything to help you unlock your account. In SAFE you and only you have the passwords, the network only serves encrypted data, the decryption happens on your personal computer. Your password never leaves your computer, it is not transmitted to the network for verification like what happens when you log in to a page on the normal internet.
Noob question, if your password never leaves your computer what if you get a new computer and want to access your safe network account is it possible to do it? or would you need a back up of some sort? or are both passwords stored in the network but the unlocking only happens on your computer? or am I totally missing the point. Thanks
“Your password never leaves your computer” is meant to be understood in the sense that your computer does not transmit it to another computer (e.g. like what happens when you log on to your gmail account.)
As for what you need to do with your password: you’ll just need to remember it
Yes, that’s it, the way it should always have been. Hardware is a commodity and should hold no value beyond the bits and pieces, but not data of value. This hardware is a target for further security, but making it irrelevant in terms of it holding our info first is a good step
Why use user-generated key material at all? It would be much more secure to generate it automatically on first run (ssh, pgp, bitcoin and whatsapp all do it that way, IIUC), and then (optionally) let the user set a passphrase to encrypt the private key at rest. Using multiple devices is a bit harder then, but apart from that it’s both more secure and way more user friendly.
IANASE but I would humbly disagree with that statement - if an attacker needs physical access to one of my machines, then that’s an extra barrier for them, right? Especially since (unlike e.g. some botnet trying to crack my Twitter password), in a decentralized network there is no central authority who can detect, judge, and block the attack. Maybe I misunderstood, but in the current setup it would be just between that botnet and the strength of my remembered secret, right? Wouldn’t it be safer to have some secret entropy stored physically on my computer, as well as in my head?
Well I mostly agree, but your data should not be available from any single device. It’s good to have a mix of trezor type devices, physical paper even plus info you know (and possibly others if you are incapacitated). My comments relate more to no peice of hardware should hold all your data or all of your access to all your data.
In decentralised networks this is where responsibility comes, we won’t rely on Google or twitter to reset our passwords or access and that is good, however we will have to give select friends the ability to do that for us if needed. All of this is not difficult with N of P sharing etc. This is the paradigm shift between centralised/controlled use of the Internet and the people being in control.
Hope that makes a bit more sense, it’s possibly a bad communication on my part.
Definitely! But I meant using auto-generated key material in addition to a user-supplied passphrase; it’s as secure on your own computer as it is now (with only the user-supplied entropy), but more secure when attacked from other devices.
IMHO the only valid reason not to use any auto-generated entropy is that hardware can fail and you don’t want to rely on it; I think the design decision here is that you want safenet to be hardware-independent.
Current topic is exactly the one that deals with the problem and after reading it, I think there is a majority of people that have expressed a preference for not using 2 passwords:
During a short period of time a name + password pair was implemented, but then it has been changed to usage of 2 passwords. And worse: not only this has been done in the front end (HMI of the launcher) but an evolution made in core prevents any change of this choice in the front end: now the location of the session packet derives exclusively from the first element which forces it to be a password to avoid collisions between users. Initially the location depended on both elements so 2 different users could pick the same name for the first element (call it the way you want: common name, pet name, friendly name …) but this evolution blocks completely this possibility.
So current implementation forces usage of 2 passwords but I think that the choice should be unblocked at the core level and the launcher HMI should be modified so that each one could make his/her own choice: use 2 passwords or use a name and a password. This could be done for example with a check box indicating that we want to use a common name for the first element and which deactivates the password strength control on it (and possibly reinforces it on the second element).
With this solution everyone would be happy: for example I could use a common name corresponding to the category of account for the first element (finance, travels, music …), but this choice is not imposed and other people could use 2 passwords instead (with strength verification on both of them). And anyone could even use both possibilities, for example I intend to take the latter choice for some hidden accounts.
I agree that the existing system is relatively unwieldy for users, but I would prefer a single robust and easy to use/understand system rather than adding options that I think will complicate it further.
I agree it will be important to have a friendly name for each account, but this doesn’t have to be part of the login - I suggested elsewhere having this as a setting within account metadata, which could be accessed and displayed (and edited) by apps. So that’s another option.
One question is: do we need two passwords?
If we do, how do we make this unusual scheme as usable as possible, while ensuring users remain secure.
If not, then can we make the system intuitive without losing security and creating difficulties with clashing friendly names.
I don’t think either is easy to solve. Both have implications for implementation, usability and security in their different ways.
Good to raise this because it’s important - one of the most crucial factors in initial impressions and overall usability.
The preference of many people (and mine) is to have one name + one password. But Maidsafe sees benefits in having 2 passwords, so I proposed an option to please everyone.
I agree that this option is a complication, but it’s only one check box whose label has to be carefully worded to make things clear. Besides it doesn’t impact the robustness of the product because it’s only a matter of HMI and the data flow remains basically the same: 2 elements sent to core that transforms them into the 3 legacy elements (keyword, pin, password).