5 ms·
What is the security of this? 1. If someone steals my laptop & breaks in, can they get access to all my history 2. After breaking, if they run `atuin key` wil
by the_arun 3y ago
What is the security of this?
1. If someone steals my laptop & breaks in, can they get access to all my history
2. After breaking, if they run `atuin key` will get them the key for my history which they can use from any device (if they know the userid)
3. If you are running servers passing passwords as command line arguments in that device, they have all that.
- fourteenminutes 3y agoIf someone steals your laptop and breaks in I think you have many problems equal to, or more severe, than your shell history.
- euos 3y agoWhat do you have in the history that’s sensitive? Keys, passwords should not be in shell history anyways (e.g. I delete them from bash history if I enter by mistake)
- extheat 3y agoI don't think it's that unusual. What comes to mind immediately is it's not unusual for me to clone something from a private git repo, where a username+password would be needed for permissions. In which case it's possible to put in `git clone http://username:password@example.com http://username:password@example.com` or another git command that interacts with remotes. (To be clear the "password" is typically a token and not human generated string, but still functions like a password).
- drbaba 3y agoFor that example: Any reason the server doesn’t just have an SSH server? Then you can use `git clone` in the “usual way”, using SSH certificate authentication.
- the_arun 3y agoShell history is wiped out after user logged out for a reason. More details are here - https://www.securityhq.com/blog/security-101-dont-bash-your-head-over-unsecured-credentials/#:~:text=An%20Attacker%20Eye%20View%20on,bash_history https://www.securityhq.com/blog/security-101-dont-bash-your-....
- drbaba 3y ago> If you are running servers passing passwords as command line arguments in that device, they have all that. I make a point out of never doing that. It’s way too easy to accidentally expose things. For instance, doing a live demo with an audience, and using Ctrl-R out of muscle memory? Suddenly you flashed your password in front of everyone. Generally, I’d recommend using a tool like Unix `pass` or your default OS keyring to store your secrets, then you can run `command1 --password=$(command2)` to feed a password from one command to another. If I really have to type something sensitive, I prefix the whole shell command with a space, which in many shells can be configured to mean that it doesn’t enter history. If you do so by accident, the shell history file can be edited in vim.
- the_arun 3y agoThis is a good approach. Thx for sharing.
- ellieh 3y ago> 1. If someone steals my laptop & breaks in, can they get access to all my history Yes, but this is the case anyway with current shell history. I think if someone breaks into your laptop you have bigger problems than your shell history. It's best to get into the habit of not pasting secrets into your shell > 2. After breaking, if they run `atuin key` will get them the key for my history which they can use from any device (if they know the userid) They would need your username, your password, _and_ your encryption key > 3. If you are running servers passing passwords as command line arguments in that device, they have all that. Yes. If you're doing this, then all of your passwords are currently stored as plaintext in your home directory - with or without Atuin. I'd consider them no longer secure if this is the case, as any program you run could read .bash_history Atuin by default comes with a set of filters to ignore secrets and not record them to history - AWS creds, slack creds, GitHub tokens, etc etc. So it may well reduce the impact of this