[the_arun]

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]

If someone steals your laptop and breaks in I think you have many problems equal to, or more severe, than your shell history.

[ellieh]

> 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

[drbaba]

> 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]

This is a good approach. Thx for sharing.

[euos]

What 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)

[the_arun]

Shell 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-....

[wswope]

Please read the page you linked; it’s flushed to a file, not wiped.

[euos]

It is not. I definitely use months-old bash history through !? shortcuts.

[extheat]

I 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:[e-mail]` 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]

For 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.