IMO:
Techies wanting to be standing out from the rest, in command of controlling, and should leave the English language well enough alone.
I’ll stick with the common, normal accepted norm.
Passphrase is a sentence used as means of securing login, or access. ‘Your dog has fleas’
Password - one line of characters together.
'QueRty’
I notice Puri likes to come up with their meaning to the same things
There is no shame in using/being same or similar to the others. God forbid one should look a teensy weensy bit it like ‘them’ others.
One can gobbledygook them into seemingly being different disagreement all one wants. The point is, they are NOT, and should NOT be the same. We have enough darned words meaning the same thing as it is.
Passphrase and Password are two different things.10-7.
It’s very silly - ‘Cell phone’, “Smartphone”, “Digital phone”
The problem I see, is where where/how techs get their education.
@irvinewade:
Just to be clear, I searched the internet for what Sharon said and my first hit explained same thing in more detail. I didn’t just trust Sharon, I also verified it by my own.
The page explained that passphrases (4-8 words) can be remembered more easily and is similar secure during the higher character count. On the other hand, passwords often are too easy, because people have to remember it and there are also studies that people tend to use insecure passwords even more if they have to full fill some password requirements (changing once per month, using specific character categories like numbers). Instead of making it stronger they tend to make passwords like asdf1234 and may change it to asdf1235 if they have to change in low time intervals.
So it is a discussion about “password vs passphrase - how to make accounts more secure”.
The danger is: In order to use a non-ASCII passphrase, the passphrase must be converted to an array of bytes (array of 8-bit values). That conversion is dependent on the environment, in particular what character set the locale is assuming. You might unknowingly change the applicable locale. You might change the locale intentionally but without realising the consequences.
Note that there are two different scenarios to consider.
The root file system is encrypted.
Some other file system (external device) is encrypted.
Obviously the latter is more benign since you can readily fix (set, even ‘compile’ if you have to) the locale before opening the LUKS encrypted volume.
man cryptsetup
for the documentation version of that explanation. From which
It is therefore highly recommended to select passphrase characters only from 7-bit ASCII, as the encoding for 7-bit ASCII stays the same for all ASCII variants and UTF-8.
So, by way of example, § is U+00A7 and is in ISO Latin 1. If your locale is set to something that uses ISO Latin 1 then it will convert to a byte of A7. If your locale is set to something that uses UTF-8 then it will convert to bytes of C2 A7 i.e. not even the same length - and certainly won’t smash down to the same unlock key.
I think the risks may be slightly overstated because for many years I have only been using locales that use UTF-8 but I guess at least for interoperability on other systems it would be unwise to assume that every system uses UTF-8.
Just for more fun … I have even seen situations where ö is represented not as U+00F6 but as ‘o’ followed by a suitable combining diacritical (U+0308). This, by definition, will only work if your locale uses UTF-8 but, again, I guarantee you that the two representations will smash down to different unlock keys (and one key will work and the other won’t).
So playing games with non-ASCII characters is both a strength and a weakness: a strength because most brute force attackers and other hackers aren’t even going to try the valid passphrase, a weakness because you might lock yourself out.
So if I see it correctly, if i change password on disk encryption for my L5 I can choose whatever I want as long as I am able to unlock it again without any risks of updating that breaks my password. So if would be a good idea to it after fresh install (or first boot) and if I’m locked out I just can reflash without any additional work (creating backups on another storage etc).
But on the same way I could encrypt my SD-card (I did btw), but can only be sure that it will work on Librem 5, but it is not clear if I try to decrypt it on my PC, that may also uses another system language?
And for L5 I shouldn’t use another system language than I used while Testing. So I should test decryption for every system language I want to use, before I start to use my system in the way I want to use?
Sounds to me, that I am save with all the characters I use. For example, I don’t plan using SD-card with any other device. So it’s more important that nobody has access to it when I lose my phone or police take it (don’t know a reason why they should, but I also know situations where they did from people who thought in the same way).
What I would do if I were locked out by this issue and assuming that we are talking about the root file system: Boot jumpdrive on the Librem 5 and attempt to open the encrypted volume on the host computer, investigating what might have gone wrong. If you can unlock on the host computer but not on the Librem 5 then you could probably fix the problem from the host (e.g. reset passphrase).
Note also that LUKS allows you to have multiple keyslots. Any one keyslot can unlock the volume. So you could in theory have a shorter passphrase that uses e.g. Unicode characters and which you normally use to unlock the volume and a longer ASCII-only passphrase that is there for emergencies. Of course you have to remember the very infrequently used emergency passphrase. Whether writing it down and storing it somewhere meets your personal security requirements is left to you.
I believe also that LUKS allows you to back up the LUKS master key. You can use the master key to decrypt the disk even if all the keyslots fail i.e. even if no valid passphrase. Obviously the master key copy must be stored securely. Again, you have to decide whether that option meets your personal security requirements.
I would half-way almost agree. My questions is, just who are those “they” that stepped in and superseded what dictionaries define as password vs. passphrase are? Shouldn’t someone be informing dictionary sites they need to adjust their view and mark them as “synonymous”.?
IMO, ‘Moore’ should re-evaluate his law. Today, we leap-frog. Can’t use new Office without the new windows that won’t work without a new computer. And within a year, all the updates take us closer to starting over… a new everything again.
Well now we get a bit philosophical. One answer is that “they” is “us”. The dictionary reflects the usage, not the other way around i.e. the dictionary does not define the usage.
Also, just because I am saying that they are synonymous doesn’t impinge upon anyone else’s right to use the words differently. We are all Humpty Dumpty.
At least one dictionary says that they are different: http://freedictionary.org/ but then clearly the distinction that it makes is arbitrary in terms of length. Some places wouldn’t even allow a password as short as length 10. In some contexts, security advice is that 10 is not adequate to survive brute force attack.
Then there is the question of the set of valid characters. If a password of length 10 is forced to use characters that are not found in a valid word then the password is no longer a “word”. My password of length 10 would be a meaningless jumble of characters - so a password of length 10 is not very different from a passphrase of a greater length.
You will note from that dictionary that “passphrase” has been around for more than 40 years. I would take that as having earned its stripes.
At the end of the day: there is a string of characters, typically known only to you, and if you don’t type it exactly correctly, you will not get access to whatever you want access to.
Today, we leap-frog. Can’t use new Office without the new windows that won’t work without a new computer. And within a year, all the updates take us closer to starting over… a new everything again.