Two passwords for login process


#61

I may have missed the part that we were talking about something that short. I must agree that would be stupid simple to crack even if it used scrypt.


#62

This got me thinking, because who says this supposedly crazywidespreadomnipresentbecoming Internet of Things won’t get botted? Now will have a vast network of relatively slow agents chewing away on our passwords, exactly in the parallel fashion that SAFE is built to handle beautifully. Just something to keep in mind.


#63

In C#, use the System.Security.Cryptography.ProtectedData class. For example, to encrypt a piece of data, use ProtectedData.Protect():

// Data to protect. Convert a string to a byte[] using Encoding.UTF8.GetBytes().
byte[] plaintext;

// Generate additional entropy (will be used as the Initialization vector)
byte[] entropy = new byte[20];
using(RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider())
{
rng.GetBytes(entropy);
}

byte[] ciphertext = ProtectedData.Protect(plaintext, entropy,
DataProtectionScope.CurrentUser);

Store the entropy and ciphertext securely, such as in a file or
registry key with permissions set so only the current user can read it.
To get access to the original data, use ProtectedData.Unprotect():

byte[] plaintext= ProtectedData.Unprotect(ciphertext, entropy,
DataProtectionScope.CurrentUser);

Note that there are additional security considerations. For example, avoid storing secrets like passwords as a string.
Strings are immutable, being they cannot be notified in memory so
someone looking at the application’s memory or a memory dump may see the
password. Use SecureString or a byte[] instead and remember to dispose or zero them as soon as the password is no longer needed.


#64

It’s written in Rust though…

It did make me think though. As it happens, libsodium has a function (sodium_mlock) to forbid swapping part of the memory, and it also advises the kernel to not include it in core dumps.

I haven’t seen it used in the Safe codebase; I wonder if it would be a good idea for sensitive data.


#65

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.


#66

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 :smirk_cat: jk


#67

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).


#68

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 :joy_cat: It’s a GAME.

This problem has been studied and experimented on, by the way.


#69

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.


#70

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.


#71

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.


#72

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


#73

Your password is in your head, where it should be, it’s not on your computer :slight_smile: Where we are going we don’t store passwords anywhere :smiley:


#74

“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 :joy_cat:


#75

Thanks for your quick response, so basically I just need to get on any computer install the software and as long as I know my passwords that’s it I can access all my data. Awesome. :slight_smile:


#76

Thanks lol yeah was a noob question :blush:


#77

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


#78

Installation is optional. All you need to do is plugin your USB drive or download the program, launch it, and you are browsing safe.


#79

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?


#80

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.