Show HN: SecureAppy – A modern vault for families
secureappy.com
secureappy.com
The very first question I’d like to see addressed in an FAQ for a “free” app or service is what the business model is and how the company expects to survive. If I start using this with others and the company goes bust in a few months, all the effort put into migrating people to this new system would be wasted. Their trust in me would also reduce.
The next question on my mind is that it claims to have end-to-end encryption, but why isn’t it open source? If it’s closed source for commercial motives, then see the first question above again.
I’m not comfortable trying a new app or service, especially one that would be used for sensitive and private data, without answers for the above. Maybe when this gets really popular and big I’ll try it, but not now.
If you have answers to my questions, please update those in the FAQ so that all visitors to your site will benefit from it.
You are probably thinkinng of "language" or "copy" :)
I use keepass for my personal passwords, for stuff I need to share. I use encryptr (https://spideroak.support/hc/en-us/articles/115003945666-Enc...). I trust Spideroak because the are transparent and I know how they are making money.
I've also used keybase some, it has free storage and encryption.
When I looked into choosing a vendor in this space a while ago, I remember Spideroak coming under a lot of fire for their use of "zero-knowledge" in marketing materials, which was at best naive and possibly much worse [1] [2]. From memory there were also issues with an unlimited plan[3][4] and refreshing contact with servers to maintain an unchanged backup.
As you say it's always sensible to pay for something you value and no one's perfect, but I wouldn't hold them up as an example of transparency done right.
[1] https://news.ycombinator.com/item?id=13852139 [2] https://news.ycombinator.com/item?id=13303436 [3] https://www.reddit.com/r/DataHoarder/comments/6lpm49/spidero... [4]https://www.reddit.com/r/DataHoarder/comments/gnfmkn/adios_s...
Why would we put photos inside the app rather than use a shared photo library?
BTW, misspelling: Militray encryption.
> Any data you save in the app is protected by military grade encryption (AES256 + PBKDF2). SecureAppy uses your passcode that only you know to encrypt and secure your data. This way, no one, not even SecureAppy can unlock or see your data.
Sorry, but 4-digit (seems to be the default) / 6-digit passcodes are trivially brute forced (for any usable PBKDF2 iterations), so that statement does not inspire a lot of confidence.
Also, I would recommend an actual security white paper detailing the design. Saying “we use AES256+PBKDF2 and end-to-end encryption” probably isn’t enough.
Another thing: passwords being default visible at rest (when you click to open an entry) may not be the best idea.
Not only should you not make a misleading security claim, I think the risk should be clearly communicated when users choose those options. The encryption may very well be sound, but it's only as strong as the passcode.
iPhone 4/6 digit passwords are secure because they require physical access to device, and they have anti-bruteforce mechanisms enforced by the security chip (eg. exponentially increasing timeouts after successive incorrect entries, "wipe device after 10 failed attempts"). Your SaaS solution provides none of that.
There is never a reason you'd want to store such sensitive data in cleartext.
It doesn't help that the security page also mentions "Militray" grade encryption.
But to date, that hasn't happened due to:
* Good syncthing handling
* Good KeepassXC merge semantics
* She rarely changes passwords to begin with, and it would be a once in a lifetime event for her and I to be doing it simultaneously.
Forgive me if I am not understanding the tools, but my impression is that if the file changed in two places at the same time Syncthing doesn't give the app a chance and just duplicates the file with two names.
So do you mean that you select all of the conflicting files in KeepassXC and it merges them? If so that seems like a nice option, I didn't realize it had that feature :)
https://docs.gradle.org/current/userguide/xcode_plugin.html https://developer.android.com/studio/build/building-cmdline https://github.com/apple/swift/blob/main/docs/Android.md https://blog.readdle.com/why-we-use-swift-for-android-db449f...
As you can see, it's a thing; hope this helps!
> It's well known that the Play Store environment is pretty much horrific for the indie developer trying to make a buck.
Yeah, Google Pay taking 30% per transaction isn't very helpful and some people choose to distribute their app outside of the Google Play Store to get around that on Android.
Does this app rectify this?
Reason I ask is... When passwords are shared between couples, neither one should be the gatekeeper with full control over access.
If you added this as a feature, it would separate your product from the existing pack.
This is of course just my opinion, others may disagree.
Our family (wife, daughter, and I) uses 1Password Family[1] and we are happy with the ecosystem that works seamlessly across devices -- desktops, phones, tablets.
Migrated from Keepass[2] to 1Password since its early beta.
I think when people realize how much data the platforms have on them, they will realize they have essentially been living in captivity. Good use case that I think is on the cusp of being big.
So I can give my wife a login for my email and I know she can't use it unless I'm incapacitated. And I can choose how many days of inactivity would qualify for the dead-man's login.
What's more likely:
1. A determined attacker targets you and causes significant uninsured irreparable harm.
2. At some point in your life you end up in hospital and your spouse is caused significant distress as they can't access an account.
0. She has poor password and security hygiene (I know this) and manages to screw it up.
-1. We get divorced.
I have delegation set up, offline backups with keepass database in and instructions that can be followed. ALL my hardware is toast though instantly.
Or maybe a lead hat because tinfoil doesn't block enough of the EM spectrum.
Also, in this day and age, "tinfoil hat" is no longer an insult. It's a given that any security leakage scenario you can imagine already happened (ie in the world where government taps all cell phone, intercepts all bits going across all telcos, and likely stores them permanently for offline cracking, and you can speculatively attack processors, tap/attack ram contents via thunderbolt or pcie, I'd take the tinfoil hat over someone wanting to do a personal insult)
> ALL my hardware is toast though instantly
It's not really a thing to insult someone over though.
me, personally, i think you did a hell of a job with this. personally i'm not going to be sharing any launch codes with my spouse, so i could care less about how industry standard and unbreakable the encryption is, but for account based credentials like netflix and spotify, this is great.
also, the landing page is spot on showcasing what this app is and how easy it is to share with others. take a bow dude and i wish you some good fortune.
Consider there are at least three copies of the data at rest: on each member's phone and more seriously, assuming also on OP's server. How long until the whole database gets breached and shows up on PasteBin?
Then as another thread mentioned, it's trivial to brute force the whole heap of vaults trynig 4-digit PINs and then look for treasure.