Hello fellow crypto friends!

I need your help on a small piece of software I'm working on: safe.

It is a pass(1)-like application used to store passwords, but I want to drop usage of asymmetric keys and use only a master password instead (ie. symmetric encryption), so all I need to do to unlock my password store is a master password.

There is one neat feature that I like with gpg though: gpg-agent. I would like to have something similar with my master password approach, so I don't have to type my password every time I want to encrypt/decrypt a password.

I know that there are multiple security implications with it, but I'm no security expert, so I would like your input/advice on this topic.

From the top of my head, here are the security concerns I should have:

• DO NOT store master password in memory --> sha256() it
  
• DO NOT store secrets in memory --> ???? I don't think I can avoid that. At least I can store smaller "chunks" for in/output
  
• NEVER keep decrypted secrets in memory --> memset() the secrets address after usage
  
• NEVER write decrypted secrets anywhere --> output to stdout only
  

What should I add to this list? Are there things I should change?

BONUS QUESTION:
Do you guys understand how the "encrypt(3)" function from unistd.h works (don't judge me) ?
It seems to take a 64bits message and return the 64bits equivalent, encrypted. Which means that my encrypted message will have the same size as the ciphertext... I'm not security expert, but it looks like a security issue right?
Answering my own question from the man page:

Quote:Because they employ the DES block cipher, which is no longer considered secure, crypt(), crypt_r(), setkey(), and setkey_r() were removed in glibc 2.28. Applications should switch to a modern cryptography library, such as libgcrypt.

Thanks for your help!

No ideas? c'mon guys...

(05-04-2019, 09:00 AM)z3bra Wrote: I know that there are multiple security implications with it, but I'm no security expert, so I would like your input/advice on this topic.

A good idea is to use block chains that will have a MAC that chains up after each passwords and maybe could be used as the next IV.
Also, why not take into account checksums in your password DB, making sure everything hasn't been tampered with.

Checksums are taken into account, as I plan to store secrets on disk by their hash, so if your secret has been tempered with, you won't find it anymore as it's filename will have changed (and I'll verify the hash after reading ofc)

Thus block chain stuff you describe seems complicated. Can it be implemented easily and without too much effort?

(12-04-2019, 05:49 AM)z3bra Wrote: Thus block chain stuff you describe seems complicated. Can it be implemented easily and without too much effort?

You can rely on the crypto library you are using to do the heavy lifting. It's probably just some parameter that you give to AES.
My idea is that you should probably chain the values so that chunks in memory can't be decrypted by themselves alone. However, that's going to be more expensive as you'll need to pass through the blocks to get to the required value.
https://en.wikipedia.org/wiki/CBC-MAC

(05-04-2019, 09:00 AM)z3bra Wrote: but I want to drop usage of asymmetric keys and use only a master password instead (ie. symmetric encryption), so all I need to do to unlock my password store is a master password.

Why?

This is more portable IMO, as you don't have to carry your key with you everywhere.
My target goal is to make it a sort of "online" pass manager accessible from everywhere, assuming you have an internet connection.
I know it can be less secure than pgp key, but I prefer simplicity over added security here.

(12-04-2019, 05:54 AM)venam Wrote:

(12-04-2019, 05:49 AM)z3bra Wrote: Thus block chain stuff you describe seems complicated. Can it be implemented easily and without too much effort?

You can rely on the crypto library you are using to do the heavy lifting. It's probably just some parameter that you give to AES.
My idea is that you should probably chain the values so that chunks in memory can't be decrypted by themselves alone. However, that's going to be more expensive as you'll need to pass through the blocks to get to the required value.
https://en.wikipedia.org/wiki/CBC-MAC

This looks interresting indeed, I like the idea that chunks of memory can't be decrypted alone. It could be problematic on small devices though, or when you have "big secrets" (namely, big data to encrypt in your safe).
Even if I don't use that yet, I'll probably think about it when designing the tool so it can be added later.

Which library would you use btw, for simple encryption? I tried to lookup libressl, but I couldn't find any documentation about using it for simple use cases (typically, take a string as input, another string as a key, and produce an encrypted output).
Any pointers?

https://libsodium.gitbook.io/doc/ try this one

This looks pretty simple indeed. I was looking at NaCl before but it's less portable it seems.
What bother me is all those *_easy() functions... When you end up with this kind of functions, it could be a bad API.

I'll start with it anyway :)

I finally made it to a stable state!
Documentation is still scarce and inaccurate, but at least the base is there and needs polishing: safe.

Here is a quick workflow video: https://p.iotek.org/l55.webm

The workflow video is dead.

Well the workflow changed already as the soft is under heavy dev :)

You might have a buffer overflow:



The n-bytes passed to strncat must also include the null byte!

Indeed, thank for pointing it out. Not a big issue though as both SOCKDIR and SOCKET are fixed strings, and they can hardly fill up PATH_MAX.

Still a bug though, that must be fixed.

(25-05-2019, 02:31 AM)z3bra Wrote: Well the workflow changed already as the soft is under heavy dev :)

Hah! I'm saying the video file you linked is literally corrupted. Unless that was the point?

I first posted the vid over p.iotek.org to share on IRC, that wasn't meant to last long.
I didn't bother reuploading it somewhere else, and now it's gone unfortunately... Sorry about that.

I said that because now I cannot record this vid again as the code change so much it doesn't work the same ^^

I'm still looking for ideas on how it should work thougg

Ok guys, so this project is going forward, and now I would need some input from other people to make it as good as possible!

Here's the idea. The password manager works by storing secrets as encrypted files on disk.
When you store a secret, you'll be prompted for your master password. This password is used to derivate a secret key, along with a random salt (that MUST be stored in some ways.
Once the key is obtained, it is used to encrypt whatever comes on <stdin> and write the encrypted stream in a file named after your entry.

This solution presents 2 problems:

1. The salt is so important that we must store it, thus putting a hard dependency on these few bytes
2. Upon encryption, the password is not verified, so we could end up with secrets encrypted from different passwords

I need to find a simple way to fix these issues, but I'm not sure how.
My first idea is that the master password is just a password like any other, so I can store it within the safe, say under an hardcoded name like "MASTER", ".lock", whatever.
Then before storing a secret, I would check that the password hash match the one from the store.

The salt could also be prepended to this "master" file, for easy retrieval. This would then set the workflow as follow:

1. User wants to store a secret, prompt for the master password
2. Read salt from the MASTER password file (first x bytes of the file)
3. Derivate key from password + salt
4. Try to decrypt the MASTER password file using the key
5. Store the secret, encrypted using the previously derived key

If the MASTER password file cannot be decrypted, then the program will refuse to store the secret.

This would require the user to initialise the store beforehand though, by providing the master password, to generate the first salt.
Something seems fishy to me with this worflow, but I cannot put my finger on it... If anyone has a comment, idea, or whatever, everything is welcome!

With the `secstore` on plan9, you lock files into a vault of sorts. It works in tandem with the `factotum` agent, which handles all authorization on behalf of the user, and secstore. You can't directly touch any files contained within*, but you can request a file, and push a file into the store. There is a lot of crossover, but the intriguing part comes from how they've separated the password management from the store, meaning that for a chicken and egg problem, you can create a password well before the store is ever created.

I use this for a few things, but mostly it works with the aforementioned factotum, which requests a list of all stored passwords from the secstore, so my session I rarely ever have to type in a password. And it's always, in every case, just my master password for factotum.

Oh right! "DO NOT store secrets in memory" --> this method uses an rpc through a tightly namespaced socket (well, it's plan9 so it's just a file read/write) from the factotum to the client program, actually in many cases to the remote service proper without the client itself even seeing the password

This sectstore + factotum looks pretty interesting. It seems a bit more "complex" though in the sense that it would handle authentication of users on behalf of other programs, like kerberos would do. It happens to provide a file encryption/vault mechanism on top of it.

I'll read it up and try to steal some ideas here and there, most likely for the agent part of my program :)

Thanks for sharing!

Definitely! I use it frequently, both on plan9 proper and via plan9port on Unix; it's quite nice, and when it's integrated well into other things it's near perfect. (The secret store could be handled in a more paranoid manner, and you could impose 2fa; but this was written quite a while ago)

It could be interesting for you to depict your current workflow with plan9 (what you use it for, why, how, ...) in a dedicated thread.
The more I work on re-implementing simple software (password manager, backup servers, ...), I end up looking at how plan9 does it the "good way" and I'm thinking more and more to setup a full plan9 server for my needs.

The factotum and secstore pair isn't without it's imperfections. Mostly due to age of it, the paranoia of the crypto isn't quite where you'd want it to be; though 9front (A plan9 fork) has done work on this front and brought the crypto to par.

Yeah I'd like that, I'll work on that over a few days' time here.

I finally released something!
The software is now usable (even though it need polishing), and you can read about it here: http://z3bra.org/safe

The repository is here: http://git.z3bra.org/safe

Tell me what you think of it ☺

This is super super cool!

I don't need all of this PGP bloat for keeping passwords. Public-private pairs are OK for bidirectional communication IMO. They're just a hassle for a password manager.
Also the agent is very fine.

I think I am going to transition to it. It would be cool if there was some Android client for it, for my phone.

Cheers!

As for the auditing part, here is what the clang static analyzer reported

Command line:

I got your patch! Thanks for that. I’ll review it and report back ;)
For android, I cannot do anything as I never programmed for it… But I have a workaround if you have an online server, so you can use ssh to retrieve your passwords over internet!

I still have to set this up someday, and I'll write a post about it.

Almost one year forward, and this software is still alive and kickin' !

I polished the documentation and made it a cool website ! I've been using it all this time, and I must say (objectively!) that it works fairly well for my needs, thanks to the agent (I use it also non interactively for cronjobs and such).

I would need a good way to fuzzy test it, and audit the code. Does anyone has content to share on this topic ?