Tag Info

New answers tagged

0

The Kali Linux Aircrack-ng suite is your best option. It uses a brute force technique to crack the standard 8 digit Key used in modern WPA/WPA2 encryption. Here is a tutorial from the official website http://www.aircrack-ng.org/doku.php?id=cracking_wpa


1

When I worry about this, I run sudo -k; sudo date && sudo -n wooden-horse-command. Then I'll be prompted for the password exactly once (by sudo date), and the sudo ticket should be fresh for the following command. Not that this gains much in terms of security, you understand. A malicious program that installs a keylogger will be more effective at ...


1

Ubuntu (and most likely many flavors of Debian) stores the information at /etc/NetworkManager/system-connections. Each of the connections has it's own file entry. The files are secured with file mode 600 and owned by root. The files in this area are not only relative to wireless settings, but information concerning your wired connections.


1

There is no standard place: this depends on the wifi connection software. For instance, wicd stores them in /etc/wicd/wireless-settings.conf (which is a bad idea since the whole configuration file needs to be protected). So, I would advise you not to store the passwords with other settings that can be readable by everyone without having to become root.


2

What the above is talking about is on the client side. To answer that, all users that can log-in (with the exception of root, see below) should not be in the local machine's /etc/passwd and /etc/shadow. Instead, those users should be in the NIS server's /etc/passwd and /etc/shadow Tip use NIS+ instead of NIS. Tip that article was written in 2003, I ...


1

> ssh -v ... gives you output which tells you how authentication was done. This is with public key: [...] debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering DSA public key: /home/hl/.ssh/id_dsa_srm ...


3

It would have been good to tell what SSH server you ask for and what (set of) Unix systems. ! and * are not passwords when you see them in /etc/passwd or /etc/shadow (use getent to read those entries). They are markers that denote whether the account has a password or not and whether it is locked or not. This is an important distinction, depending on the ...


1

Whatever the user wants it to be, considering any policies on password complexity. If the only access is via SSH and PasswordAuthentication is no in sshd_config, then it does not matter what the password is. Also note that entries in shadow are encrypted passwords, so the values of ! and * are not passwords - but strings which are not valid encrypted values, ...


1

To avoid showing the password on the command where other users can see it with ps, you should not pass the password in the command. It's why many utilities don't support passwords as command line arguments. Instead store your password in a ~/.netrc file and pass the -n option to curl. For the details of file syntax, I let you see the man of curl.


1

You can't configure Linux not to require sudo. Some commands need to be executed as root; if you want to trigger them from an unprivileged account, sudo or some other privilege escalation mechanism is necessary. You can configure sudo not to require a password for specific commands, by adding a sudoers rule with the NOPASSWD: tag. Note that NOPASSWD rules ...


0

Use visudo to configure your /etc/sudoers file. You probably want something like this: ALL ALL=NOPASSWD: /usr/bin/apt-get See man sudoers for details. If you really want to avoid sudo altogether you can set the sticky bit like this: chmod u+s /usr/bin/apt-get Whether this works depends a bit on the application. This way the command runs as effective ...


0

If you set password aging at all then pam_unix.so is going to deny their authentication after the password expires. To do what you're wanting you can probably add something to their login scripts. For example, I can add the following to /etc/profile.d: #!/bin/bash maxDays=30 dayLastChanged=$(passwd -S $(whoami) | awk '{print $3}') currentTimestamp=$(date ...


0

If you're not averse to using a custom script, try this as a pam_exec script: #! /bin/bash LAST_DATE=$(date -d "$(chage -l $PAM_USER | awk -F: '/Last password/{print $2}')" '+%s') TODAY=$(date '+%s') MAX_AGE=60 if (( (($TODAY - $LAST_DATE) / 86400) > $MAX_AGE )) then echo "Please change your password!" fi Save it somewhere (say, ...


0

@Giles The only potential culprit I see in your configuration is pam_ldap, if LDAP is misconfigured somehow. Yep, commenting it out solved the problem.



Top 50 recent answers are included