NAME

kc — console based username and password management application

SYNOPSIS

DESCRIPTION

kc is a console-based username and password management application using an encrypted XML document as its database. The database file is encrypted with a key that is generated from a user-supplied password and/or a security key and/or an SSH agent. Database encryption (and thus decryption) can be interactive or non-interactive in that it could require user input (i.e. a password), or a response for a challenge from a security key or a signature from an SSH agent. See the PASSWORDS section on how these work in terms of generating a password.

A database file can contain multiple keychains, and keychains in turn can contain multiple keys (usernames if you like) and values (passwords if you like).

After starting kc the help command shows the available commands, and usage information for them. If you're in a hurry, for starters, you create a new entry with the new command and save it with write. You can see the stored keys with the list command, then entering only a number in the command line will display the entry with the given index. You quit from the value display with ‘q’ or EOT (usually CTRL+d).

The CLI supports tab-completion for commands and keychains.

When saving the database (write command) kc will create a temporary file (under the same directory as the opened database file), and will first try to save the whole database to that temporary database file. When this succeeds, only then will kc replace the old database with the new one, so you will always have a usable and intact (but potentially older) version of your database file.

On OpenBSD kc tries to use pledge(2) but see also the CAVEATS section.

EXAMPLES

Creating a new database:

Using a password with the encryption key generated by bcrypt:

$ kc -P bcrypt -k ~/.kc/my_passwords.kcd
Creating '/home/user/.kc/my_passwords.kcd'
Using '/home/user/.kc/my_passwords.kcd' database.
New password (empty to cancel):
New password again (empty to cancel):
<default% >

<default% > status
Database file: /home/user/.kc/my_passwords.kcd (/home/user/.kc/my_passwords.kcd)
XML structure size: 148 bytes
Password: yes
SSH agent: no
YubiKey: no
Password function: bcrypt (36 rounds)
Encryption: aes256, cbc
Read-only: no
Modified: yes
<default% >

Using an SSH agent without a password:

$ ssh-add -l
256 SHA256:3fxFML/VoUOvFr5WDPsiJH8E8dwM0/27IZtoVW7Cz/g my_private_key (ED25519)

$ kc -A ssh-ed25519,my_private_key -k ~/.kc/my_secrets.kcd
Using '(ssh-ed25519) my_private_key' identity for decryption
Creating '/home/user/.kc/my_secrets.kcd'
Using '/home/user/.kc/my_secrets.kcd' database.
<default% >

<default% > status
Database file: /home/user/.kc/my_secrets.kcd (/home/user/.kc/my_secrets.kcd)
XML structure size: 148 bytes
Password: no
SSH agent: (ssh-ed25519) my_private_key
YubiKey: no
Password function: sha512 (100000 iterations)
Encryption: aes256, cbc
Read-only: no
Modified: yes
<default% >

Using a YubiKey security key and a password:

$ kc -Y 2,password -k .kc/passwords_and_secrets.kcd
Using YubiKey slot #2 on device #0 and a password
Creating '/home/user/.kc/passwords_and_secrets.kcd'
Using '/home/user/.kc/passwords_and_secrets.kcd' database.
New password (empty to cancel):
New password again (empty to cancel):
Remember to touch your YubiKey if necessary
<default% >

<default% > status
Database file: .kc/passwords_and_secrets.kcd (/home/user/.kc/passwords_and_secrets.kcd)
XML structure size: 148 bytes
Password: yes
SSH agent: no
YubiKey: Slot #2, Device #0
Password function: sha512 (100000 iterations)
Encryption: aes256, cbc
Read-only: no
Modified: yes
<default% >

Adding new entries:

Simple:

<default% > new testuser
<default% NEW value> testpass

Prompt for both key and value:

<default% > new
<default% NEW key> testuser2
<default% NEW value> test_\r_pass_with_random_characters:\A

Using the 'key' only as an indication:

<default% > new www.mysecuresite.com
<default% NEW value> user_name\npass-word

Using the random and newline character sequences:

<default% > new testuser3
<default% NEW value> \r\R\n\a\A\nthis is a multiline value!

Creating new keychains:

<default% > cnew email_accounts
<default% > cnew
<default% NEW keychain name> WebSite Accounts
<default% NEW keychain description> description

<default% > cnew 2
<default% NEW keychain description> Two
Created keychain: 3. 2

Displaying, listing entries:

Listing the keys in the current keychain:

<default% > list
0. testuser
1. testuser2
2. www.mysecuresite.com
3. testuser3

Displaying values in the current keychain:

<default% > 0
[testuser] testpass
<default% > 1
[testuser2] test_,x_pass_with_random_characters:6nzm
<default% > 2
[www.mysecuresite.com] [1/2] user_name
[www.mysecuresite.com] [2/2] pass-word
<default% > 3
[testuser3] [1/3] v#)z!9
[testuser3] [2/3] HwRz7i
[testuser3] [3/3] this is a multiline value!

Listing keychains:

<default% > clist
0. default
1. email_accounts
2. WebSite Accounts
3. 2

Switch to another keychains:

<default% > c email_accounts
<email_accounts% > c 2
<WebSite Accounts% > c 3
<2% > c 2
<WebSite Accounts% > cc 2
<2% >

Editing existing entries:

Edit an entry in the current keychain:

<default% > edit 1
<default% EDIT key> testuser2
<default% EDIT value> test_pass_with_random_characters:6nzm
<default% > 1
[testuser2] test_pass_with_random_characters:6nzm

Rename a keychain:

<default% > cedit
<default% EDIT keychain name> my_own keychain
<default% EDIT keychain description> description
my_own keychain% >

pwsafe_to_kc.pl:

# Export the pwsafe database to a cleartext file:
$ pwsafe --exportdb > pwsafe_export
Enter passphrase for .pwsafe.dat:

# Convert the cleartext pwsafe database to a kc XML database file:
$ pwsafe_to_kc.pl pwsafe_export kc_db.xml
opening pwsafe_export for reading.
opening kc_db.xml for writing.
Converting...
Done.

After the above commands, you should end up with a kc compatible XML database. You can import it to kc using the importxml command.

AUTHORS

kc was written by LEVAI Daniel <leva@ecentrum.hu>

Source, information, bugs: https://github.com/levaidaniel/kc

CAVEATS

Fair warnings before using the clipboard features:

1. If you don't trust the system where you're running kc then don't use these features, as you can not be sure that the binaries in your PATH are not tampered with and would record the passwords.
2. Removal of the values from the clipboards are not being dealt with. This should be the user's responsibility.

SSH agent support:

1. The password (signature) coming from ssh-agent(1) varies between different types of SSH keys — different keys/key bit lengths produce different signature lengths.
2. kc cannot handle spaces in the key comment when using the export or import commands. Opening a database however, works with spaces in the key comment.

YubiKey HMAC challenge-response:

1. Supports an at most 64 bytes long password.
2. Only HMAC mode is supported by kc
3. Maybe it goes without saying, but this method of password protection is not quite useful over network connections (e.g.: SSH on a remote machine), as the actual device is not plugged in there. There is, however, a USB-over-IP implementation for Linux that could overcome this.

Miscellaneous:

1. It is considered a good practice, to periodically manually backup the database file(s) you use with kc. This could just mean a simple:

   $ cp ~/.kc/default ~/.kc/default-bkp

2. kc doesn't try excessively hard to recover from hard and/or non-recoverable errors (OS, memory, disk etc...), and in some cases this could mean that it will simply exit (without saving the database) with an appropriate error message. No need to worry, but keep this in mind like you would with a common word processor or text editor and save periodically, for example when you edit many keys at once.
3. There is no character set conversion taking place in the program. In this case this means you must be ready to display anything you type in. If somehow you still end up with texts you can not display properly, and for whatever reason you can not edit them in kc, you can "repair" such database by dumping its content to a kc XML file (see the dump command), converting the plain text XML file to a working character set, then importing back that XML file (see the importxml command).
4. If you use cfb, ctr or ofb as the cipher mode, there is no specific sign if you enter a wrong password during opening a database; in this case the database will seem to be corrupt after decrypting, and kc simply will not be able to open it.
5. On OpenBSD kc uses pledge(2) to restrict its access to certain functions, but only when not compiled with YubiKey support. Currently the way yubikey libraries access USB devices cannot be allowed by any promise for pledge(2).
6. There is a Perl script in the source package (available from the project website) that converts an exported pwsafe database to a kc compatible XML database, which can be imported using the importxml command. NOTA BENE: This script is really old and not maintained.