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.
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.
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.
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.
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.
1 Like
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
1 Like
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.
1 Like
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 is in your head, where it should be, itâs not on your computer 
Where we are going we donât store passwords anywhere 
4 Likes
â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
2 Likes
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.
4 Likes
Thanks lol yeah was a noob question 
1 Like
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
2 Likes
Installation is optional. All you need to do is plugin your USB drive or download the program, launch it, and you are browsing safe.
2 Likes
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?
1 Like
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.
4 Likes