Discussion about the password requirements in SAFE Launcher

He’s spot on. People get mad when their password gets denied. Even the smartiest people get angry when their favorite password is rejected or called “insecure”.

In my opinion we want to stray away from any “negative calls”.
“Negative calls” like telling someone their password choice is less than subpar has lasting subconscious effects.

Like the error sound from Windows XP. I set that as my ringtone and my entire office was in a bad mood for WEEKS.

6 Likes

So with the password thing, thinking out loud and not really thought through, so free free to ignore it :slight_smile:

I agree somewhat with @whiteoutmashups and others who call for warnings rather than blocking the use of insecure passwords. I may just want a testing account that I will ditch 20 minutes later

Using the fact that at the moment and forseeable future we will have a maximum brute force password cracking at < 5 times a second (maybe 2 per second) we could perhaps have

  • if password/passphrase can be broken in a day or two (500K tries) of continuous testing then reject as too easy
  • if the password/passphrase can be broken in 1 month continuous attack (10 Million tries) then make the user jump through a few warnings to use the p/w. This will prevent grandmas child from attempting to get her files/money by manually trying to crack her password, and only if someone really wanted to crack her p/w would they continue beyond a couple of days.
  • if the password/passphrase can be broken in 10 months (100M tries) then just a warning that has to be clicked on should suffice. This password will likely survive most attacks anyhow.
  • if broken in 1000 months (10 billion tries) then just a warning
  • no warning beyond that,

These warning can also appear when they use their password/passphrase since the launcher can check each time. That way if conditions change then what may have been secure previously but not now the user can be warned that their password/passphrase is not as secure and be able to change it.

4 Likes

Why not offer forcing a timeout for a day after 5 consecutive failed tries ?
That would make it hard to get into cracking most passwords with a max
of less than 2000 tries per annum … , and avoid dumb network requests .

How would one enforce this?

The launcher is opensource and simple to remove that limitation

The group nodes receiving the request only get the decoded “address” from the password(s) so the address will likely change on each try. So even if they had a concept of time they still could not limit the tries, since one IP address could represent 100 or 1000 computers behind a college router.

Also then its a state that the group must remember for all that try. It could become a very large table of “tries” from various IP addresses and for various “addresses”

2 Likes

about the secure password issue what about Using stuff like first name, last name, city of birth, user name and password have the computer “remember” first name, last name and city of birth have the user only use a nice 6 digit user name and 6 digit password and if the user uses another computer have all fields be required and if the user name and password is tried unsuccessfully 3 times have all the fields be required.

if we are not confortable sharing this then three other questions that pertain to you only… first girlfriend, pets name, street address of where you grew up.

Glad to see progress. Some points of observation:

  • It’s concerning that someone (in this case maidsafe) is making decisions on behalf of users about password strength. This is a network about choice. Weak passwords should be allowed (albeit with a strong warning). Don’t censor my weak password!

  • The ‘information’ is confusing on the create account slides (slides 2 and 4). It doesn’t contribute to making a better decision on slides 3 and 5. To see what I mean, read those slides in the voice of your mother, then ask yourself in the same voice “why does that matter to me?”. Truth is, that information doesn’t matter. I reckon remove slides 2 and 4. Slides 1,3,5 are good without 2 and 4 getting in the way.

  • Entering a password first then secret second will probably be more comfortable for most users. This achieves a few things:

    • It creates a familiar first experience. Not many users have entered a ‘secret’ before, but everyone has entered a ‘password’. Being shown a familiar field as the first step of signing up will make novice users more comfortable.
    • It removes the incorrect correlation between username/password and secret/password that novice users will subconsciously form.
    • It gives the secret it’s own ‘feel’. Normally the password is the last thing entered in a login form. Putting the secret after the password makes it feel like a-third-thing, even though a username is never actually entered. Maybe this is my own experiential bias speaking.
  • Being really pedantic now, but the first slide of the create account should use a fullstop instead of a comma at the end of the first line.

The safe network is so incredible; I want to share it with everyone. Most people are not tech nerds, so I’m really interested in making a glorious ‘first impact’ with the interface. The interface is basically the only thing most people will know about the safe network, so let’s make it as incredible as the underlying tech! :slight_smile:

5 Likes

IF WEAK PASSWORDS ARE AN OPTION, IT IS GOING TO BE THE DEFAULT.
This is the typical human behavior, and it is the constant everywhere and those who has some experience dealing with users will agree.
In the end it will end up undermining the network as a whole, maybe not structurally but its reputation will definitely get tarnished when hordes of idiots start popping up online bitching about getting hacked through brute forced or even by getting it guessed.

I think there should be something didactic that is easy to remember but that has high entropy.
I was just imagining the following: Imagine a random generator that generates a random animation. The user after seeing the short animation has to invent a title or simply describe what he just saw, and then remember that title he just created. The randomly generated animation should be absurd enough to leave a long lasting impression (classic mnemonics), and every movement and element would be randomly generated for each user.

There are about 1500 nouns in English and there are an extra 1500 verbs in our everyday usage, with two actions (verbs) and three elements (nouns) we get a combination that is roughly 1500^5.
From which each user will have the freedom to interpret it as they wish and remember it easily as it is visual, which adds an extra randomness to its process as we can’t really predict what they will come up with.

After the user enters the title or the description just below the animation, make it repeat it again a separate screen this time without the animation, and then a third time just to make sure they got it.

4 Likes

The same ones who will write strong passwords on a post-it-note, or save it to passwords.txt? It’s not about enforcing a choice, it’s about informing it. Help ‘idiots’ be smarter.

The animation idea is interesting. Sorta like a wordlist so you know that showing 3 images from a set of 1500 is about 1500^3 = 32 bits of entropy. But the word choice depends on the user so it’s actually stronger than that.

3 Likes

600 days to crack is acceptable? Are you NSA?

With 3 objects with 2 actions, it would have 52.7 bits of entropy.
With 3 objects with 3 actions, it would have 63.3 bits of entropy.

This theoretical max might be actually smaller since some actions and objects might have synonyms and homonyms, I guess that to get a better estimate we should know which words are semantically unique among those 1500 nouns and verbs.
For instance, turning, twisting, spiraling, patrolling, rolling and twirling could be animated in the same way and that would drastically reduce its entropy…

But you also have French, Arabic, Yiddish, emoji etc :wink:

that’s true, we just have to pray the “horde of idiots” don’t type “I don’t know” when we ask for the title. lol

There’s a lot of off topic about passwords in this thread!
I wonder the original was best, with three elements that inherently create a strong mix.

Allowing weak passwords, is like allowing the network to not do what it does best and creates risk, rather than ensuring SAFEty.

2 Likes

Would 2FA be achievable on safe?

1 Like

It’s a reasonable assumption , password first , then secret may indeed be
psychologically a bit more familiar or introductory to some , if not the majority .

I don’t think it cannot be given a try in the next test version ,
but it may be also confusing to those paying less attention …

600 days to crack is only an estimate based on one entity trying to access at a pace ,
what if several divide the total workload while iterating simultaneously through the
possibilities ? That would considerable lower the total time to break into one’s account .

Btw. : What’s 600 days of running some software to get hold of something truly valuable ;
it’s not even work that has to be attended continuously . Password strength ought to hold
way over 100 years , and there should be a mechanism to prevent dividing the workload ,
in my view on this . Special thought should be given to introduce long delays ( e.g. 24h )
after a few ( e.g. 5 ) failed consecutive tries , and even increase the delays upon the next
failed series to 48h . A counter mechanism built into the network core itself , able to trigger
and adjust itself . That I imagine ideal . However , such a mechanism would use up some of
the network resources to keep track for 24-48 hours of access attempts for a particular
account and it would have to be also encrypted in order to prevent outside snooping .

There is probably a way to calculate the tracking mechanism workload for a hypothetical
range of use load at any given time and in total , including peak access time use cases .
This information needs to move across the network relatively easy and the entire
mechanism may not be feasible unless it is executable on a footprint small enough .

How do we implement a counter that allows only a few numbers of accesses into a decentralised and encrypted network like SAFE , not into the launcher but into the protocol itself ? Is there a nifty hack of
mapping something that exists encrypted and has a changing address — what about using additional opcodes + () ?

Just ideas , I’m sure we can learn more as we bounce them and as technically more
versed experts and geniuses chime in to dissolve or separate the fog from the sight .

If such a mechanism can exist we must find it and seek to optimise its execution down to the assembler level if necessary . Sometimes , multiple speed gains are possible by using better code or a more powerful function in C or ASM . Another pit is all platforms must be covered which is a hurdle or could be an impossible goal due to the different ways they work …

Hey , to all who came so far : it wasn’t me who broke your mindful continuum :robot: thanks for reading this :hotdog: