The safe 3. profile configuration.?

Help for Current Versions of MX
When asking for help, use Quick System Info from MX Tools. It will be properly formatted using the following steps.
1. Click on Quick System Info in MX Tools
2. Right click in your post and paste.
Message
Author
User avatar
CharlesV
Administrator
Posts: 7995
Joined: Sun Jul 07, 2019 5:11 pm

Re: The safe 3. profile configuration.?

#61 Post by CharlesV »

Veracrypt, is the best you can do. Of course, you MUST unmount it, everytime you stop using your data.
Actually, all of my mounted, encrypted veravrypt vaults dis-mount when my machine sleeps. (I also saw it dis-mount when I locked too.)

And @andy you have some good points. Clearing cache, cookies and history is #1 for privacy AND to keep things quiet on the machine. (I do this for privacy already.)

Truly, one of the best things I have seen for 'being safe' is to create the controls and methods that work best, then write it all to a USB without persistence and then fire THAT up under a VM.

And yes, dont attempt to create it all yourself, unless you have some training and experience.
*QSI = Quick System Info from menu (Copy for Forum)
*MXPI = MX Package Installer
*Please check the solved checkbox on the post that solved it.
*Linux -This is the way!

andy
Posts: 101
Joined: Tue Oct 26, 2021 1:08 pm

Re: The safe 3. profile configuration.?

#62 Post by andy »

Jakob77 wrote: Tue Jul 25, 2023 6:48 am Andy
...
He says something about a secret username also can be important because it will force the cracker to guess that too, and that will make it much more difficult.

If that is true in this context it tells me that we need the root password to be significantly stronger than the others. Not just because root has the most privileges but also because it is the only username the cracker likely knows for sure.
...
Consider using key-based authentication.
If we are talking about SSH prompt, open from outside, I have some research already done.

I will illustrate it on the use case of SecureShell service. If you need to administrate your computer from remote location, you are leaving SSH service running and accessible from outside. In case of using normal typed password, this will expose the option to try to login to your device to practically everyone, if not restricted to particular IP addresses.
So without further hardening of the system, the attacker can try very many different passwords. Weak passwords mean fewer tries for actually finding them.
Passwords with greatest strenght (it is called entropy - how big the haystack, where attacker is searching your needle, is), which are absolutely resistible to this type of attack, are unfeasible to type.
By making passwords reasonably short and/or rememberable (and I mean no "short" ones, but 12-16 characters at least, truly random, with special characters), they become weak to some types of attack.
So for SSH, this problem is solved by using pre-generated keys.
good info here:
https://www.cyberciti.biz/tips/linux-un ... tices.html
https://www.digitalocean.com/community/ ... nux-server
https://linuxhandbook.com/known-hosts-file/
https://tylercipriani.com/blog/2017/09/ ... ascii-art/
https://stribika.github.io/2015/01/04/s ... shell.html

How it should work, when you need to authenticate yourself to such system? In a nutshell, you must first generate your keyfile (you can protect this keyfile with its own password, then it will become double protection). Then, you setup your server to accept your particular keyfile, by uploading the public part of the keyfile to your server. Then you can access your server from some remote location by using your private part of the keyfile and by providing the passphrase to unlock or decrypt this private part of your keyfile on the device (SSH client) from which you are connecting to your server. Then the SSH client will be able to prove to your remote SSH server, that it really is the one who is allowed to go in.
Obviously, you must keep your private keyfile confident. If it leaks, its strenght shrinks only to the strength of the passphrase by which it is encrypted.
But if the keyfile is only in possession of you, and nobody else, the strength of this authentication is astronomically greater. (4096 bit in comparision to say 80-120 bit with normal 12-16 character random password). Adding each bit doubles the size of the haystack, which hides the "needle" - the password/keyfile.
"Guessing the keyfile" is essentially impossible, with any hardware ever known, even combined. (except one particular kind of hypothethical future quantum computers).

So, if an attacker has some access to your system, albeit not root access, and you are using just normal password, maybe he can bruteforce your password. In this case you can make his life much harder, by using this technology for ordinary local authentication. You gain enormous robustness against attacks by brute force.
You have to search yourself, or somebody can provide links, as I have not made my research this way yet.
Just a quick search. I meant exactly this.
https://linuxconfig.org/linux-authentic ... usb-device

Anyway, I need some confirmation of an expert, if this particular solution is really secure and do not have backdoors or weaknesses, because I do not know nothing about that particular fork, and seems suspicious to me why
The pam_usb software, once widely available for installation on any major Linux distro, no longer exists in any package repositories.
But it is cheap (you need just USB key), and available.

Regards,
Andy

Jakob77
Posts: 661
Joined: Thu Feb 09, 2023 3:09 am

Re: The safe 3. profile configuration.?

#63 Post by Jakob77 »

CharlesV

Safe, safer and safest...

The safe 3. profile is safest if it is on a 3. computer with no demands for safety. ;)


There has been problems with malware from the installer for ClipGrab but I think that is another Windows biased issue that has not much to do with MX. At least I haven't been able to spot any bugs.
I do wonder about how an application can be allowed to scan the disk, history or the clipboard without permission. I truly dislike it but ClipGrab is not the only one doing it.

So I download some clips to the 3. profile on the 3. computer and from there I can just copy them to other computers to be watched off-line in a better protected environment.
There could perhaps be a virus in a file infecting my VLC but I believe it is a risk I am prepared to take.

About the commands for network activation/deactivation and maybe the USB-unmounting I am afraid it is too much of a jungle for me so I might have to make requests for it. In my opinion it could be very good if it was made a tradition by the developers to put the name of the Terminal command behind the function in the mouse tooltip.



andy

Thank you for a lot of interesting points.
If you think it is about solving one huge and urgent security problem with a very specific enemy you misunderstand.
It is the first time I have been working with more user profiles on the same Linux computer, and I find it very interesting to explore how it works in MX and discuss what can be gained by it concerning data safety. Interesting disagreements and points about safety just makes the subject grow.

andy
Posts: 101
Joined: Tue Oct 26, 2021 1:08 pm

Re: The safe 3. profile configuration.?

#64 Post by andy »

Jakob77 wrote: Fri Aug 04, 2023 8:07 am andy
...
If you think it is about solving one huge and urgent security problem with a very specific enemy you misunderstand.
...
Hi @Jakob77,
of course I did not think exactly that, it would be too late to defend yourself in such situation.
This type of defense, if it should have at least some chance to be feasible, must be done way way ahead.
Prepare everything, before one start to use computer with critical data.
To prepare yourself, learning opsec.

Post Reply

Return to “MX Help”