Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keepassxc-cli passwords as parameters #6752

Open
dawidol opened this issue Jul 20, 2021 · 11 comments
Open

keepassxc-cli passwords as parameters #6752

dawidol opened this issue Jul 20, 2021 · 11 comments

Comments

@dawidol
Copy link

dawidol commented Jul 20, 2021

Summary

Hi :)

We are working on a web applicaction and we want to storage sensitive information in a kdbx file, we are trying to use keepassxc-cli to achieve this, but it looks like there is no way to send password as parameters without the terminal prompt

Examples

Create a new Database
keepassxc-cli create -p "SomePassword" /path/to/file
keepassxc-cli add -p "SomePasswordForAnEntry" /path/to/File entry

Context

Any lights on how to achieve this will be very helpful.

Thanks

@droidmonkey
Copy link
Member

You need to pipe the password into stdin.

@dawidol
Copy link
Author

dawidol commented Jul 20, 2021

Hi, thanks @droidmonkey
Indeed that did the job for creating de database:

echo InsecurePassword |keepassxc-cli create file.kdbx

but if I want to add a new entry I need to send first the database password and after that the password for the new entry. Any idea on how to send 2 consecutive strings to stdin.

Thanks again

@droidmonkey
Copy link
Member

droidmonkey commented Jul 20, 2021

Use printf and add a newline in between. https://linuxize.com/post/bash-printf-command/

I'm not sure why we don't have a password parameter. It is generally bad practice to supply one on the command line call, however piping one in is no better technically. Any thoughts @louib ?

For entry creation we definitely encourage using the generator options to make a new random password. You can retrieve it later using show command.

@dawidol
Copy link
Author

dawidol commented Jul 20, 2021

Thaks @droidmonkey

Yes we are generating passwords on several parts, there is only one place when we want the user have the hability to write a password or choose to generate.

Also printf with a new line, creates the new entry but leave the password as an empty value, this is the command i put:
printf "InsecureDBPassword\nNewPassword" |keepassxc-cli add file.kdbx newEntry
Thanks again

@droidmonkey
Copy link
Member

You'll need to enter the password twice (pw\npw\n) since there is a confirmation step.

@louib
Copy link
Member

louib commented Jul 20, 2021

I'm not sure why we don't have a password parameter. It is generally bad practice to supply one on the command line call, however piping one in is no better technically. Any thoughts @louib ?

I think the main reason why we don't have a parameter for that is because we underestimated how much people would rely on the CLI as a secure database backend. If both piping and parameters end up in the shell history, I guess we could add both for convenience. We might want to better highlight that those invocations might be logged though.

@dawidol
Copy link
Author

dawidol commented Jul 20, 2021

Thanks @droidmonkey looks like is not working for me, here is a screenshot.

image

thanks again

@droidmonkey
Copy link
Member

You need to add "-p" to the add command to prompt for password. Recommend reading the help for the commands.

@dawidol
Copy link
Author

dawidol commented Jul 20, 2021

I did try with "-p" option and didnt work, here is the output

image

@strk
Copy link

strk commented Oct 18, 2021

The stdin way works for me, with 2.6.1
I'm missing the database parameter, but that's another story :)

@phoerious
Copy link
Member

phoerious commented Oct 19, 2021

It is generally bad practice to supply one on the command line call, however piping one in is no better technically. Any thoughts @louib ?

I know that comment is older, but just to clarify: Providing passwords on the command line is bad practice because it will be stored in your shell history and appear for all users in the list of processes (unless you have user-level process namespacing turned on, but even then it's bad and root can always see your password). Piping is always the better option therefore, since pipe contents never appear in the process cmdline. Shell history recording can be easily avoided as well by simply piping from a file or some other source instead of typing it literally into the shell. On the cmdline, your only option is to prefix your command with a space and that's very shell-specific.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants