2 files changed, 173 insertions(+), 0 deletions(-)

A content/2022-12-27-password-manager/index.md
A content/2022-12-27-password-manager/padlock.svg

@@ 0,0 1,130 @@
++++
+title = "Simpler password manager"
+
+[taxonomies]
+tags = ["password", "app"]
+categories = ["programming"]
+
+[extra]
+image = "padlock.svg"
+image_alt = "Padlock clipart."
+image_credit = "<a href=\"https://svg-clipart.com/black/YNlqc0x-padlock-icon-clipart\">LindaPer</a> / CC BY 4.0"
++++
+
+Until we can finally get rid of passwords by means of some form of public/private key cryptography we will
+need to juggle too many passwords.
+
+<!-- more -->
+
+Currently I have over 540 passwords and other secrets stored in my password manager.
+While I understand that I am a special case here, I still believe that most people will need to keep way more
+passwords and other secrets around than they can be possibly remembered or they will reuse few easy to crack password variants.
+This puts them at risk of data loss, phishing attacks and other harms.
+
+# Requirements of password manager
+
+We all need a password manager that has the minimum following properties:
+
+* be accessible at all times (including in off-line situations),
+* be reasonably secure against theft,
+* resilient against loss,
+* trivial to set up,
+* quick to access and use,
+* free (including not getting locked in).
+
+# Existing solutions
+
+Today you can use web services, that are often paid and may try to lock you in or may not work off-line.
+Or you can build your own solution based on tools [KeePass](https://www.keepassdx.com/) or [pass](https://www.passwordstore.org/) (GPG + Git).
+
+The problem with web solutions is that they are complicated to set up: require accounts, passwords, recovery kits, applications and what not.
+Them being on-line have massive attack surface (over the internet) and act as massive honey pots/all eggs in one place.
+Or require complex juggling of database files, key files, git repositories or other file synchronization tools.
+
+# For the expert
+
+Personally I use `pass` command with GPG key for encryption and Git for synchronization between few of may devices.
+I have used [KeePassXC](https://keepassxc.org/) with Dropbox before, but that was causing synchronization conflicts.
+
+While this works fine for me and is powerful in may ways, there is no easy solution that I can recommend to
+my friends or family.
+
+# For the people
+
+The main issue that these existing systems try to address is multi device synchronization. But from my experience
+this is not required (only convenient). As long as I can see the password I can just type it in and be done.
+
+If we could store the password DB in out mobile computers, that we carry around with us all the time in secure
+and resilient way, that should be already a major upgrade for most people.
+
+# Existing solutions
+
+Take a project like KeePass DX and simplify the work flow.
+The main problem I have with KeePass applications for mobile devices is that they require you to align three things:
+
+* the database file location,
+* the location of the key file (optional but probably require to be secure against password cracking/phishing, since any app can leak the DB file, especially if "cloud" storage is used),
+* the password itself.
+
+If any of these things is wrong you can't access your passwords.
+Whet makes it worse is that you can set this up for someone, but sooner or later they will click the wrong thing
+or the OS update will change file access URL, or it will expire or they will forget the password and all data is
+now inaccessible.
+
+# Proposed changes
+
+To eliminate the moving parts imagine this simplified work flow for Sam:
+
+## Setup
+
+1. Install the application form the app store (e.g. I can send a link via chat to the app).
+2. The application generates random recovery password.
+3. This password is presented to Sam in form of password words, serial key or something that is easy to write down.
+4. Sam is asked to write it down on piece of paper that they need to then store securely at home (e.g. in safe).
+5. Sam is then asked to retype the password to verify it is correctly written down.
+6. Once this is verified the app asks for fingerprint authentication.
+7. The password is stored in OS secret store protected with this biometric authentication and device secure element.
+8. New KeePass compatible DB file is created with the password in application private storage space (so not accessible by other apps).
+
+Note: Alternative OS authentication method can be used, like pin number, face ID or whatever the OS supports.
+
+## Use
+
+1. Open the app.
+2. The app pops up fingerprint authentication.
+3. After Sam authenticates the password is retrieved from the device secret store and used to decrypt the internally stored DB file.
+
+Now, you use it the same way you would use stock KeePass DX.
+
+## Import and Export
+
+In order to allow Sam to migrate data to new device or to off-site backup the app would need to allow:
+
+* Exporting the KeePass compatible database to external storage by asking Sam for new password, optional key file and file location and name.
+* Importing data by merging with existing records from KeePass database file on external storage, giving file location, password and optional key file location.
+
+This is important as we don't want to lock the data in the application/device.
+
+## Backups and restore
+
+The app would allow for existing application backup tools (e.g. default Google cloud backup) to back up the internal database
+along with the app itself.
+
+Because the password to that file was protected by secure element on the original device, restoring it form backup
+would not itself allow for access to the data.
+
+So on first run of the application:
+
+1. The application would not be able to retrieve the database file password from the OS secret store (new device).
+2. It will ask for the recovery password that Sam has written down on the first use.
+3. It will pop up fingerprint authentication and store the password like with first use.
+4. Continue as normal from now on.
+
+This way we can make sure the passwords are not lost in case of device loss or breakage and are still safe to be stored in the backup.
+
+# Conclusion
+
+Given this can be implemented, it should help people secure the digital (and physical) lives with ease while preserving their freedom.
+
+I have created a [Feature request](https://github.com/Kunzisoft/KeePassDX/issues/1468) on KeePassDX GitHub repository
+with the proposed solution.

@@ 0,0 1,43 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   version="1.0"
+   width="700"
+   height="300"
+   id="svg2394"
+   sodipodi:docname="padlock.svg"
+   inkscape:version="1.1.1 (3bf5ae0d25, 2021-09-20)"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg">
+  <sodipodi:namedview
+     id="namedview952"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     inkscape:pagecheckerboard="0"
+     showgrid="false"
+     inkscape:zoom="0.8142466"
+     inkscape:cx="279.39939"
+     inkscape:cy="170.09589"
+     inkscape:window-width="1916"
+     inkscape:window-height="1030"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="svg2394" />
+  <defs
+     id="defs2396" />
+  <g
+     id="layer1"
+     transform="matrix(0.66327498,0,0,0.66327498,167.72531,-16.270548)">
+    <path
+       d="m 97.357129,434.70306 c 2.023662,12.10662 12.532641,21.30195 25.207301,21.30195 H 383.8685 c 12.67465,0 23.18363,-9.19533 25.2073,-21.30195 z M 122.56443,235.88479 c -14.13028,0 -25.562372,11.43204 -25.562372,25.56234 V 416.95142 H 409.43088 V 261.44713 c 0,-14.1303 -11.4321,-25.56234 -25.56238,-25.56234 h -15.58595 c 0.21304,-2.9468 0.31955,-66.24912 0.31955,-69.2314 0,-63.72838 -51.65726,-115.385638 -115.38564,-115.385638 -63.72836,0 -115.38563,51.657258 -115.38563,115.385638 0,2.98228 0.10651,66.2846 0.31956,69.2314 z m 175.95419,0 h -90.60431 c -0.56806,-2.87579 -0.85211,-66.17813 -0.85211,-69.2314 0,-25.49134 20.66293,-46.15422 46.15426,-46.15422 25.49136,0 46.15428,20.66288 46.15428,46.15422 0,3.05327 -0.28404,66.35561 -0.85212,69.2314 z"
+       id="path14"
+       style="fill:#2c2c2c;fill-opacity:1;fill-rule:evenodd" />
+  </g>
+</svg>