I have just migrated to Ubuntu and tweaked the Unity Desktop environment to my heart's content. I wanted a nice flat material design theme for my desktop. Everything went well but the launcher_bfb button didn't change. It still had a shadow and a glow. After googling I found out that the icon is placed in the following directory: /usr/share/unity/icons
.
The launcher_bfb icon is made up 13 different png and svg images (atleast in Ubuntu 16.04), namely,
- launcher_bfb.png
- launcher_icon_back_54.svg
- launcher_icon_back_150.svg
- launcher_icon_edge_54.svg
- launcher_icon_edge_150.svg
- launcher_icon_glow_62.svg
- launcher_icon_glow_62.png
- launcher_icon_glow_200.svg
- launcher_icon_selected_back_54.svg
- launcher_icon_selected_back_150.svg
- launcher_icon_shadow_62.svg
- launcher_icon_shadow_200.svg
- launcher_icon_shine_54.svg
I just replaced these files (except the first one) with blank png/svg files of same dimensions and it worked for me.
To prevent offline brute-force attacks.
Even though you can't reverse a hash, you can still try hashing every possible password until you find a match, and you can do millions of tries per second with good hardware and local access to the file.
If the file had 644
permissions, then anyone who logged in to your system, even in a guest session, would be able to copy this file off of your computer (whether to a USB stick or remotely via scp
) and attempt an offline brute-force attack, without leaving any evidence of this on your computer.
Note that the permissions on Ubuntu are actually 640
, not 600
:
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1239 Jun 25 04:35 /etc/shadow
This doesn't matter much though, since there are still no permissions for others, and, by default, no one is in the shadow
group.
Originally, hashes were stored in /etc/passwd
(which is why it's called passwd
), as back when Linux was created, cracking a hash, even the weak types used back then, was practically impossible. Eventually, though, processing power advanced to the point where cracking a hash, at least of a relatively weak password, became feasible.
Changing the permissions of /etc/passwd
to 640
or 600
wouldn't work, as there are many legitimate reasons to be able to read /etc/passwd
as a normal user (converting UIDs to usernames, getting a user's full name, phone number, etc), so hashes were moved to /etc/shadow
, which was given 640
permissions. An x
in place of the password hash field for a user in /etc/passwd
is used to indicate that the hash for that user is stored in /etc/shadow
instead.
Best Answer
This doesn't have a valid password hash:
On Linux, the password-hashing algorithms are DES, MD5, SHA-256 and SHA-512 (see
man 3 crypt
, not counting Blowfish), and the length of the password hash you have given doesn't match the lengths output by any of these (13, 22, 43 and 86 characters respectively, where yours is 75 characters long). and further, it doesn't have a salt or algorithm identifier. The system will try to read it as a DES-hashed value, with the first two characters being the salt - but who knows what password will match it then?