Guide to User Data Security
inversoft.com
Guide to User Data Security
1–10 of 25 posts
Re: Guide to User Data Security
#2>By forcing users to select secure passwords you will prevent users with accounts on your servers from using passwords like "password".
or you know, disable password login and use ssh keys.
Re: Guide to User Data Security
#3>By forcing users to select secure passwords you will prevent users with accounts on your servers from using passwords like "password". or you know, disable password login and use ssh keys.
If you disable passwords, then you need to use password-less sudo. That's usually not a great idea. Users still need passwords, they just need to be secure.
For SSH, yes, keys should always be used and the guide covers disabling password and root SSH logins. Here's section 4.5:
> Remote access is always through SSH on Linux servers. In most cases, SSH is setup to allow access to user accounts via passwords. By allowing users to log in to your server using their passwords, you allow hackers to brute force attack your server from anywhere in the world. Instead, your servers should use RSA keys to allow users to login. This will only allow users to access the server from the computer that contains their private key. Since private keys will be password locked and never shared, this will ensure that only authorized users will be able to access the server.
Re: Guide to User Data Security
#4>By forcing users to select secure passwords you will prevent users with accounts on your servers from using passwords like "password". or you know, disable password login and use ssh keys.
If you disable passwords, then you need to use password-less sudo. That's usually not a great idea. Users still need passwords, they just need to be secure. For SSH, yes, keys should always be used and the guide covers disabling password and root SSH logins. Here's section 4.5: > Remote access is always through SSH on Linux servers. In most cases, SSH is setup to allow access to user accounts via passwords. By allowi…
How do you keep users from selecting easy passwords (or no password) for their private keys?
Re: Guide to User Data Security
#5Earlier quoted context omitted.
If you disable passwords, then you need to use password-less sudo. That's usually not a great idea. Users still need passwords, they just need to be secure. For SSH, yes, keys should always be used and the guide covers disabling password and root SSH logins. Here's section 4.5: > Remote access is always through SSH on Linux servers. In most cases, SSH is setup to allow access to user accounts via passwords. By allowi…
How do you keep users from selecting easy passwords (or no password) for their private keys?
The libpam-cracklib does it for you. It's a PAM module that is invoked whenever the user changes their password. You can configure it to enforce various password constraints and rules.
Check out section 4.4 for a detailed overview of Cracklib.
Re: Guide to User Data Security
#6>By forcing users to select secure passwords you will prevent users with accounts on your servers from using passwords like "password". or you know, disable password login and use ssh keys.
If you disable passwords, then you need to use password-less sudo. That's usually not a great idea. Users still need passwords, they just need to be secure. For SSH, yes, keys should always be used and the guide covers disabling password and root SSH logins. Here's section 4.5: > Remote access is always through SSH on Linux servers. In most cases, SSH is setup to allow access to user accounts via passwords. By allowi…
> If you disable passwords, then you need to use password-less sudo.
unfortunately that's true. But it shouldn't have to be. There is a libpam-ssh-agent-auth which makes use of a forwarded ssh-agent socket to authenticate to whenever sudo needs it, which means that you have to re-authenticate your ssh-key locally.
It works, but it never really took of, and tbh I wouldn't trust it's security. But the authentication flow is something I would want.
Re: Guide to User Data Security
#7Uhm...
> "Guide to User Data Security"
> TL;DR If you're to lazy to read all of this, just run these scripts that we have prepared for you, to totally secure your servers!
Why would they give out advice like that ? Is that supposed to be a test?
Does this replace all the files on your servers with:
>Lesson One: Don't give random script you find on the internet access to your servers without even reading about what they do?
Security isn't a product that you can just slap on to an existing system and feel good about being secure. One would think that that should be somewhere in the first paragraph on any guide to User Data Security.
Re: Guide to User Data Security
#8Earlier quoted context omitted.
How do you keep users from selecting easy passwords (or no password) for their private keys?
The libpam-cracklib does it for you. It's a PAM module that is invoked whenever the user changes their password. You can configure it to enforce various password constraints and rules. Check out section 4.4 for a detailed overview of Cracklib.
You're answering the wrong question. They're asking about passphrase for SSH key not OS user accounts.
Adding a passphrase to your SSH private key is a best practice but not easily enforced without some manual process or command and control for sysadmin workstations.
Hardware tokens containing private keys and used via PKCS#11 are another option for providing some assurance. The token itself can require a PIN.
Re: Guide to User Data Security
#9Earlier quoted context omitted.
If you disable passwords, then you need to use password-less sudo. That's usually not a great idea. Users still need passwords, they just need to be secure. For SSH, yes, keys should always be used and the guide covers disabling password and root SSH logins. Here's section 4.5: > Remote access is always through SSH on Linux servers. In most cases, SSH is setup to allow access to user accounts via passwords. By allowi…
> If you disable passwords, then you need to use password-less sudo. unfortunately that's true. But it shouldn't have to be. There is a libpam-ssh-agent-auth which makes use of a forwarded ssh-agent socket to authenticate to whenever sudo needs it, which means that you have to re-authenticate your ssh-key locally . It works, but it never really took of, and tbh I wouldn't trust it's security. But the authentication f…
Search for "ssh agent forwarding attack" or similar.
Re: Guide to User Data Security
#10Uhm... > "Guide to User Data Security" > TL;DR If you're to lazy to read all of this, just run these scripts that we have prepared for you, to totally secure your servers! Why would they give out advice like that ? Is that supposed to be a test? Does this replace all the files on your servers with: >Lesson One: Don't give random script you find on the internet access to your servers without even reading about what th…
Thank god the scripts are open source. You can actually read them and figure out what they do. Shocking!