I think a big reason why password managers tend to have native apps is so that the OS can better integrate with them. For example, iOS' `AuthenticationServices` API which can autofill username & passwords from a third party password manager. I don't think PWAs can achieve this yet. Personally I use Bitwarden, which offers both native and web client for all of my devices.
In any case, still very good to see more choices out there, and congrats on launching!
Thanks for the comment!
I know Bitwarden, I think it may be great alternative for "mainstream" password managers. It's whole ecosystem.
But, what I wanted is something much simpler in terms of regular usage, hosting "custom" instance, tinkering. Something which is highly optimised and does only one thing.
Do you use Bitwarden on iOS/iPadOS? How do you get it to auto fill anything? It's quite cumbersome changing Windows back and forth just to copy-paste some fields.
I would also say that storing your most valuable secrets in the same process that interacts with untrusted and potentially malicious content (ads, etc) might not be the best idea.
If you're willing to check how it works, then official instance is here https://passwords-fountain.com/, but you can easily create your own, even free of charge (you need only static site hosting).
I hope you'll like it and I'm opened to your feedback.
Agreed, I'd prefer to use all ten fingers at a keyboard on a desktop web interface than waste time with just two on a mobile device. It's just a more productive way to spend your time. Also, I don't have an unlimited data plan anymore, since why would you ever need one if you're social distancing 100% of the time? Ideally I'd switch to prepaid. Half the time I forget where my phone is, and I'm much happier for it.
I see a lot of claims regarding controle of data. But only 1 option (Fauna.com) as to actually store the passwords. (Or am I missing something).
This would mean I do not only need to trust your code. I also need to trust this totally 3rd party with my passwords...
Further you list it works everywhere, but are missing a cli variant (so not everywhere).
As to the trust claim in the fake exchange between the 2 people. Nobody talks like that, if they do not want to use a password manager it is always another reason than trusting the code. (Or all you would need is some audits to create that trust)
It just gives the feeling (to me) this is a piece of software looking for a problem to fix.
"But only 1 option (Fauna.com) as to actually store the passwords. (Or am I missing something)."
This is because I wanted to get some opinions from potential users before I'll invest more time in developing it and provide them with more options and additional tooling e.g. like CLI which I didn't even consider before (thanks again).
Even though this app looks very simple it took me a lot of time to get me to this point and release it as it is.
I know that most users don't give a *t, but I did care about the code quality, no without a reason.
I wanted to make it easy to tinker and personalise - you don't have to wait for me to change / add database provider or e.g. until I make it works without them.
"Nobody talks like that, if they do not want to use a password manager it is always another reason than trusting the code."
I think you used "nobody" here the same way as I used "everywhere". Sometimes it's hard to evade generalisation, but I was thinking about devices with GUI.
> We don't store any vulnerable data - your passwords neither land on localStorage, sessionStorage, IndexedDB nor any server.
> In your database (https://fauna.com/) passwords are stored in encrypted version so nobody can steal them from there.
So fauna is not a server and not something running local in the browser from my reading of the above. Looking at fauna.com it seems like it absolutely runs on servers, just as a SaaS. What am I missing here?
Or do you just mean that the passwords are not stored on your servers?
1. You can decrypt only one password at once. It's stored in memory then. Rest of passwords remain encrypted and they are also stored in memory after being downloaded.
It means that after webpage / PWA is being refreshed (or closed) you have no passwords (in any form) in the memory.
2. Passwords Fountain is using famously safe symmetric algorithm (AES-256). I think it would be hard use asymmetric approach in current architecture with staying user friendly in any way.
Please note that there is no server between this app (interface) and Fauna (database) and I'm strongly against storing something needed to password decryption both in database (e.g. private key) and the browser.
Becuase of that - you have to remember and protect your master key.
Remember that you also have your dashboard after logging into FaunaDB account. You can verify database connections anytime you want.
3. MFA is quite serious feature and this would need also server code which I wanted to avoid as much as possible - it's making creating custom instance harder.
Also - I suppose, I would have to force users to use an additional app for this purpose e.g. Google Authenticator (because I don't want to pay for any SMS service), which would make the regular usage strongly inconvenient.
4. Decryption key is stored in local variable (in memory) only for the moment it's really needed (from the moment after getting it from the user to putting it into decryption / encryption function).
After this tiny time frame that aforementioned variable is getting back to its default value which is an empty string.
I hope you have now better understanding of how it works. If not - don't hesitate to ask additional questions ;)
I completely understand your point of view, but I think that at this point it's more likely to add additional db providers / options to establish app <-> db connection, than listing some niche app on fauna.com.
Anyone in the tech industry, which is Hacker News' target audience, knows what PWA means.
And it's gaining ubiquity outside the industry as well; a search via Qwant (so not personalized) tells you that it stands for Progressive Web Application. The only other contender for the front page is Public Works Administration, which isn't remotely applicable.
[+] [-] poyu|5 years ago|reply
In any case, still very good to see more choices out there, and congrats on launching!
Edit: word
[+] [-] koloboss12|5 years ago|reply
But, what I wanted is something much simpler in terms of regular usage, hosting "custom" instance, tinkering. Something which is highly optimised and does only one thing.
[+] [-] httpsterio|5 years ago|reply
[+] [-] Nextgrid|5 years ago|reply
[+] [-] koloboss12|5 years ago|reply
It's basically PWA app written in Preact with the help of other micro-sized libs like goober.js (CSS in JS).
Whole codebase can be found here https://github.com/kolodziejczakM/passwords-fountain.
If you're willing to check how it works, then official instance is here https://passwords-fountain.com/, but you can easily create your own, even free of charge (you need only static site hosting).
I hope you'll like it and I'm opened to your feedback.
[+] [-] kuba-orlik|5 years ago|reply
[+] [-] cryptoquick|5 years ago|reply
[+] [-] Sysosmaster|5 years ago|reply
This would mean I do not only need to trust your code. I also need to trust this totally 3rd party with my passwords...
Further you list it works everywhere, but are missing a cli variant (so not everywhere).
As to the trust claim in the fake exchange between the 2 people. Nobody talks like that, if they do not want to use a password manager it is always another reason than trusting the code. (Or all you would need is some audits to create that trust) It just gives the feeling (to me) this is a piece of software looking for a problem to fix.
[+] [-] koloboss12|5 years ago|reply
"But only 1 option (Fauna.com) as to actually store the passwords. (Or am I missing something)."
This is because I wanted to get some opinions from potential users before I'll invest more time in developing it and provide them with more options and additional tooling e.g. like CLI which I didn't even consider before (thanks again).
Even though this app looks very simple it took me a lot of time to get me to this point and release it as it is. I know that most users don't give a *t, but I did care about the code quality, no without a reason. I wanted to make it easy to tinker and personalise - you don't have to wait for me to change / add database provider or e.g. until I make it works without them.
"Nobody talks like that, if they do not want to use a password manager it is always another reason than trusting the code." I think you used "nobody" here the same way as I used "everywhere". Sometimes it's hard to evade generalisation, but I was thinking about devices with GUI.
Once more, thank you!
[+] [-] SahAssar|5 years ago|reply
> In your database (https://fauna.com/) passwords are stored in encrypted version so nobody can steal them from there.
So fauna is not a server and not something running local in the browser from my reading of the above. Looking at fauna.com it seems like it absolutely runs on servers, just as a SaaS. What am I missing here?
Or do you just mean that the passwords are not stored on your servers?
[+] [-] koloboss12|5 years ago|reply
[+] [-] munchbunny|5 years ago|reply
1. Are your passwords encrypted whenever the bits aren't on your physical device?
2. Are you using asymmetric cryptography to make sure only you hold the key to actually decrypt the passwords?
3. What forms of MFA do you support for authentication in order to open your vault/decrypt your passwords?
4. Where are you storing the decryption key?
[+] [-] koloboss12|5 years ago|reply
1. You can decrypt only one password at once. It's stored in memory then. Rest of passwords remain encrypted and they are also stored in memory after being downloaded. It means that after webpage / PWA is being refreshed (or closed) you have no passwords (in any form) in the memory.
2. Passwords Fountain is using famously safe symmetric algorithm (AES-256). I think it would be hard use asymmetric approach in current architecture with staying user friendly in any way. Please note that there is no server between this app (interface) and Fauna (database) and I'm strongly against storing something needed to password decryption both in database (e.g. private key) and the browser. Becuase of that - you have to remember and protect your master key. Remember that you also have your dashboard after logging into FaunaDB account. You can verify database connections anytime you want.
3. MFA is quite serious feature and this would need also server code which I wanted to avoid as much as possible - it's making creating custom instance harder. Also - I suppose, I would have to force users to use an additional app for this purpose e.g. Google Authenticator (because I don't want to pay for any SMS service), which would make the regular usage strongly inconvenient.
4. Decryption key is stored in local variable (in memory) only for the moment it's really needed (from the moment after getting it from the user to putting it into decryption / encryption function). After this tiny time frame that aforementioned variable is getting back to its default value which is an empty string.
I hope you have now better understanding of how it works. If not - don't hesitate to ask additional questions ;)
[+] [-] lucideer|5 years ago|reply
Unless this is a product marketed exclusively at Evan Weaver, CEO of fauna.com, then this is not "my database".
[+] [-] koloboss12|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] hacker_newz|5 years ago|reply
[+] [-] Nextgrid|5 years ago|reply
[+] [-] Youssefbekour|5 years ago|reply
[deleted]
[+] [-] kylek|5 years ago|reply
[+] [-] dehumanise|5 years ago|reply
[+] [-] prophesi|5 years ago|reply
And it's gaining ubiquity outside the industry as well; a search via Qwant (so not personalized) tells you that it stands for Progressive Web Application. The only other contender for the front page is Public Works Administration, which isn't remotely applicable.