My Triskel 9 Security Guide
Hey guys, heres a short guide on how to secure your Triskel 9 Installation.
1st Install Triskel 9 with a Full Disk Encryption Passphrase. I reccomend a 20+ character passphrase for most users, and 150+ character passphrases for the most security focused persons.
I typically just choose a long book or movie title, and type it 3 or more times, then add special characters.
For example:
"TheLionTheWitchAndTheWardrobeTheLionTheWitchAndTheWardrobe22&&"
Would be a decent passphrase.
Next, once Triskel 9 Is booted, install a Firewall, I use "ufw".
sudo apt-get install ufw
sudo apt install ufw
just type "ufw" into terminal and the terminal will tell you the commands to install ufw.
Once UFW is installed, enable it.
"sudo ufw enable"
Then, UFW will be enabled and run on system startup.
=)
Great, now I reccomend using a VPN to encrypt your network traffik.
ProtonVPN Free is great for most users, so Make a ProtonVPN account, setup the Linux command line tool, and connect to a US-Free#1 server.
As for browsers, I use Firefox, with Privacy Badger, Ublock origin, and Decentraleyes add-ons installed.
Enjoy secure internet usage. I hope this guide helped you.
I also am using a Libreboot x200s Triskel 9, for refrence.
I typically just choose a long book or movie title, and type it 3 or more times, then add special characters.
That is actually less safe than much shorter and arguably easier-to-remember passwords, such as four random words taken in /usr/share/hunspell/en_US.dic. In https://trisquel.info/forum/one-line-password-generator#comment-119846 I gave a command line to generate such a password and explained:
Since /usr/share/hunspell/en_US.dic contains 62,155 different words, the command I gave above can output 62,155^4 = 15 billion billion (sic) different passwords. A tool that tries one billion passwords per second takes more than 236 years (in average, knowing the password is four words in /usr/share/hunspell/en_US.dic) to crack the password. Against more serious enemies (e.g., a state agency targeting you) "capable of one trillion guesses per second" (as Edward Snowden wrote to Laura Poitras, as shown in Citizenfour) that number decreases to 86 days.
The parenthesis "knowing the password is four words in /usr/share/hunspell/en_US.dic" matters: assuming the attacker knows the generation method is standard practice in cryptography. Using the same assumption, your method does not get to 15 billion billion different passwords.
Indeed, the title you choose is probably that of a rather famous book or movie. Even if it is really obscure, it still certainly belongs to the list of the one million most famous books or movies. Repeating it "3 or more times" certainly means "between three and six times", because your willingness to type the same long title over and over is limited. As a consequence, the uncertainty on the number of repetitions only multiplies the number of possible passwords by four. Finally, assuming you randomly choose your special characters in a set of 50 characters, your four-character suffix (in your example) is actually responsible for most of the entropy: 50^4 = 6.25 million. Multiplying the three number: 1M * 4 * 6.25M = 25000 billion.
There are 600000 times more passwords composed of four words in /usr/share/hunspell/en_US.dic. They are faster to type (fewer characters) and do not require remembering a random sequence of special characters. The same "tool that tries one billion passwords per second [and] takes more than 236 years" to crack the four random words would only take, still in average, less than three hours and a half to crack your long password (still under the generous assumptions I made above, such as picking an obscure book or movie that forces the tool to try hundreds of thousands of titles).
Answer me this then if you have time:
If any key: A B " ( <
can be used for a passphrase, how is a movie title or book title, any less secure than the diceware generators? If its the same number of characters.
Thanks
As I wrote, "assuming the attacker knows the generation method is standard practice in cryptography".
When cracking a password, the dictionary attack is tried before the brute-force attack: https://en.wikipedia.org/wiki/Dictionary_attack
The dictionary can contain the titles of one million books or film. The cracking tool can repeat the word taken from the dictionary and can append a few random characters. Doing so, your password can be found within hours, with a guessing rate of one billion password per second. You can check my math. If it is correct, your password generation method is roughly as strong as three words randomly picked in /usr/share/hunspell/en_US.dic, because 62,155^3 = 240,120 billion, but it is far less practical. I believe anyone prefers to type the following three words rather than "TheLionTheWitchAndTheWardrobeTheLionTheWitchAndTheWardrobe22&&":
$ words=3; dic=/usr/share/hunspell/en_US.dic; max=$(wc -l < $dic); for i in $(seq $words); do r=$(od -A n -N 4 -t u4 /dev/random); cut -d / -f 1 $dic | sed -n $(expr $r % $max + 1)p; done | tr '\n' ' '
desideratum flat emeritus
Trying each and every type-able password (brute-force), the password-cracking tool would never find the password you generated, because it contains 20+ characters. In that context, there is not even a need for special character: with an alphabet of 26 characters, 26^20 = 2e28. But, I repeat, that is not the context we live in: the dictionary attack is tried before the brute-force attack.
Thanks for the script. We now know how to generate strong and easily memorized passphrases, like this one:
Garfunkel dyspepsia sharpen
I thought I might use it to encrypt my /home partition. When I figured out how many times I would have to type it, I deemed it wise to run your script at least once more.
I am remembered of a supposedly robust way of generating memory-friendly passwords by choosing an existing word, switching some of its characters to make sure that lowercase, uppercase, digits and special characters were used while keeping it close enough visually to the original (like "feasibility" -> "fE4si_b1L1ty" for instance) to be still easy to remember. The passwords thus generated usually get scores of "only" 150 million years to 20 billion years of brute force attack resistance, depending on their length (from 12 to 15, respectively). I guess more powerful attackers using smarter techniques might reduce this to almost no time.
The technique is again to follow the generation method. Assuming the word is picked in /usr/share/dict/words (102,305 words, with up to 23 characters, 8.4942 in average) and three possible variations per character in average (lowercase, uppercase, and one special character resembling the letter), you get 454 billion different passwords:
$ awk '{ s += 3^length } END { print s }' /usr/share/dict/words
453547211187
With one billion guesses per second (that I have been using until now), it takes minutes to break the password. Moreover, most of the 454 billion different passwords come from the largest words. Since it would be hard to remember variations for many characters, you would probably not choose a very long word... and the cracker would also start with the smaller words. Here are, for words of upper-bounded sizes (maximal size in the first column), the times (in seconds, in the second column) for the cracking tool to test all the variations up to that size:
$ awk '{ for (i = length; i < 24; ++i) s[i] += 3^length } END { for (i = 1; i < 24; ++i) print i, s[i] / 1e9 }' /usr/share/dict/words
1 1.56e-07
2 1.344e-06
3 2.3268e-05
4 0.000287409
5 0.00193811
6 0.0103726
7 0.0438512
8 0.150782
9 0.443921
10 1.15292
11 2.70774
12 5.7529
13 11.0891
14 19.3349
15 32.335
16 49.3385
17 72.3255
18 100.22
19 136.25
20 171.118
21 202.499
22 359.404
23 453.547
Passwords with up to 16 characters do not even resist one minute. You may argue that you can come up with two special characters per letter, in average. I do not think it is that easy (and it certainly makes the password harder to remember). Executing the same command as above but substituting the 3 with a 4, you will see that, up to 16 characters, those passwords do not resist one hour of cracking. That is better but still not good enough.
Sorry, I missed your post at the time. Thanks for computing what indeed amounts to a ridiculously short time required to crack a password thus generated.
I had a feeling it might not be overly resistant, now I have a stronger feeling about that.
I guess the IT department people who suggested using that method thought it would always be better than anything from short series of number, actual dictionary words or anything with any sort of personal significance to the user, assuming that a potential attacker would not know the generation technique (I am not sure how strong the assumption was in that particular case).
Also, there was an increasing delay between each retry or a limited amount of trials before the account would be locked, which I guess was the main security mechanism.
The "one-billion guesses per second" supposes an unfortunately common scenario: a hash of your password stored in a database that was compromised. The cracker has it on her computer and uses GPGPU to crack it. If, instead, the attempts go through the Internet, there is no way to reach such a high guessing rate.
Through the Internet, a server that does not impose delays between attempts cannot handle more than 1000 sign-in requests per second, I believe. If so, the password you showed (well, maybe not exactly that one: it may have entered a dictionary thanks to this thread!) should resist about one month (I just multiplied by one million the 2.70774s I found in my previous post for 11 characters). Probably enough unless you are specifically targeted.
Anyway, do you consider that "fE4si_b1L1ty" is easier to remember or more convenient to type than two random words taken in the dictionary? The latter is actually a little more resistant.
Pretty basic stuff actually, but good for people who don't know the first thing about security.
I would recommend changing VPN for Tor Browser. That would also solve the issue of browser/device fingerprinting.
And change habits, which is the most important thing in terms of security... Most people could have the most secure machine in the world, and they would screw it up in 10 minutes, because of their habits (installing anything from everywhere, clicking all "accept" buttons on every website and every software, posting their entire life and mind and soul in social media... It's a problem of culture not technology.
Thanks for the thread anyway.
> how to secure your laptop
I have a feeling that the above experience is valid for any type of device and not limited to laptops.
> It is a difficult time when our data is sold to corporations and does not respect a person's freedom
Security, privacy and software freedom are clearly separate matters that only partially overlap and would better not be mixed (imho) in order to avoid adding confusion to complexity.
> Tor Browser. That would also solve the issue of browser/device fingerprinting.
Not sure about that. See for instance https://blog.torproject.org/browser-fingerprinting-introduction-and-challenges-ahead. Notice that in the examples given, the "platform" parameter (probably extracted through JS from the value of navigator.platform) is in fact the same in Firefox and in Tor Browser, which would most probably be enough to give a TB user on any GNU/Linux OS an almost unique fingerprint since the user agent has been spoofed in TB (and not in FF, making in fact the same user possibly more difficult to uniquely identify on FF). This is a typical example of how tricky anti-fingerprinting can get. Spoofing your browser's fingerprints is one thing, not making it too obvious and thus too unique is another. The author himself - a "full-time researcher on computer security and privacy with a touch of software engineering" - seems to be marginally confused about what values actually get modified by TB, writing that "other visible changes include the platform, the timezone, and the screen resolution." Well, in the fingerprint examples he provides the value returned for the platform visibly does not change: "Linux x86_64".
This thread provides quite a thorough guide of all the levers available to make Abrowser even more privacy friendly. There is clearly no one-off solution, no tool should be blindly trusted, no piece of advice taken for granted. Humbly educating ourselves is the only way.
Here is something I do to add a layer of protection.
I go to https://github.com/StevenBlack/hosts and update my /etc/hosts file.
You scroll down the page to get to the collections, I just go with Unified hosts = (adware + malware).
These days you never know how many or which domains are part of a web page you look at. Currently, Unified hosts = (adware + malware) lists 60,413 domains of bad actors. If your /etc/hosts file is set up like the one he gives out, those bad domains will never get loaded up because the hosts file supplies their IP as 0.0.0.0, the road to nowhere. You browser will replace whatever element it was supposed to get with the message that Firefox could not find this server.
If you're looking into VPNs I'd suggest PenguinVPN.
https://www.thinkpenguin.com/gnu-linux/penguinvpn-subscription-1-6-and-12-month-options
ThinkPenguin products support Trisquel, sometimes shipping with it by default as in here:
https://www.thinkpenguin.com/gnu-linux/penguin-mini-c-edition-gnu-linux-desktop
Its CEO is
https://trisquel.info/en/users/chris
and is an Associate Member of the Trisquel Project and thus actively and regularly helps support it.