5

I have found a bug and the developers to whom I reported this bug to want me to send them the VM with the bug. They want me to send them the password and the VM in its current state (a snapshot). I don't want to give them the password I currently have for the VM, instead I am going to change the password for the VM to something else, and I don't want them to be able to figure out what my old password was.

So if I change the sudo password and give them a snapshot of the machine, with access to the machine and the new password is there any way that they could determine the old password? The machine is an installation of Ubuntu GNOME 15.10 with GNOME 3.18 64-bit.

I'm basically just wanting to know if it is still stored somewhere or something, and whether I'd be safer just doing a fresh install with a password I don't mind giving away, or whether once the password is changed, the old one can't be recovered and thus it doesn't matter if I just send them a snapshot with a new password.

Braiam
  • 69,112

2 Answers2

9

No, the password is only stored in /etc/shadow and, even there, it is stored salted hash. This means that even if they have the original password hash, it is very very hard to get the actual password from it. You would have to brute force it and, if it is even possible, it would take a long time and far more resources than anyone would be willing to expend just to get some random panda's password.

In any case, when you change your password, the entry in /etc/shadow is changed and no trace of the original password remains.

You should, perhaps, check through your shell's history and make sure you never entered the password in plain text there:

 history | grep yourPassword

You could also, for your peace of mind, run a full search on all files on the virtual drive:

 find / -type f -exec grep -l "yourPassword" {} +

Mind the space in front of the commands. That makes it so that the commands are NOT added to history.

terdon
  • 104,119
6

You are better off creating a fresh VM, recreating the bug, then send that fresh copy to the developers, with nothing of value to you in what you send them. If you consider all the possible places you can get random text strings saved (shell history, auth.log, compressed logs, etc.), you will still have doubts that you thought of them all, or checked throughly enough.

example: Type your password when the username was expected, that gets saved in /var/log/auth.log, old auth.logs are compressed. What about other logins like ssh? Confident you got all the operating system places? Now consider what sort of logging the VM program may be doing. Far less work to start with a fresh, known clean VM, and duplicate the bug. Also, the developers will appreciate a known state (fresh install) which displays the bug.

ubfan1
  • 19,049