As someone who develops for iOS and Mac, I sometimes ask: why put in the effort of making it cross platform? Most Apple users are happy in their ecosystem, and they pay for apps. Android would not allow for developing in Xcode and Swift, and also the users don't really pay for apps. It's well known that the Play Store environment is pretty much horrific for the indie developer trying to make a buck.
I used to work for a team doing app matching, finding apps that exists in both ecosystems and yes, most IOS apps which didn't have a match were more used than Android apps with no match
> 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.
Yes, but I feel that this context is a little bit different: here the assumption is that both partners (or tuples) have iOS, which is probably pretty rare (at least from my experience, EU based)
This seems weird. Most password managers already have sharing capabilities and family controls. Why would I use this given it seems I need to enter passwords manually and am limited to iOS.
Hi damnencryption - although other popular password managers offer a sharing feature, we felt like it was still cumbersome to use for a normal user. We tried to make this app dead easy to use and share sensitive information. Also, the premium plans with other password managers that offer sharing can run high for family plans. This app doesn't also have a restriction on how many ppl you share with. Essentially, if you are running a small business and need to share some sensitive information with your co-workers, you can do that too with no problem.
You could also set up KeepassXC with a shared database, synced to a shared Dropbox account. And if you want to spend money, go donate to the KPXC devs.
KeepassXC is pretty good about intelligent merging, and in the rare case it can't, Syncthing will (IIRC) dump another file out with a filename indicating that IT couldn't sync correctly. So I'd have to manually figure it out.
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.
> KeepassXC is pretty good about intelligent merging
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 :)
No; I mean if KeepassXC sees a local change and one that came in from "outside" (eg: via syncthing), it will Do The Right Thing more often than not. I assume that if my wife and I change the same record in incompatible ways it might not be able to handle that, but if she adds a password and I remove or modify a different one, it should be able to merge those changes without issue.
Hi draugadrotten - this free version will always remain free. Unless you are sharing, the pictures you store are encrypted and stored on your own device (basically using your iCloud storage). That's why we don't incur a huge cost. However, we are planning to introduce premium features in the future including a cloud storage option for people who don't have enough disk space on their device.
We use Notes for that on iOS. The advantage is that it then syncs to all of your other devices, be it your iPad, work Mac or your phone. Not sure if it syncs to Apple Watch yet. Does this app have any significant advantages over that approach? I like the design.
> 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.
Hi oefra! Thanks for the feedback. We wanted to provide the same security pattern that iPhone's provide - 4 digit, 6 digit and alphanumeric. This gives the user the power to determine their own security depending on the type of information they are planning to store. Also, based on the overwhelming feedback here on security details, I think we will publish a white paper soon to make it more clear :)
So it's not military grade? It's average clueless user grade? Isn't the value of product like this to provide good security without the user having to be an expert?
AES256+PBKDF2 does qualify as "military grade" in the security marketing space, AFAICT. Which is pretty meaningless. You can have the best cipher, and the best KDF, but nothing would save you if your key is derived from "1234".
There's nothing wrong with allowing a 4-bit passcode. The problem is that you're claiming "no one, not even SecureAppy can unlock or see your data" which is just not true when the user uses a 4-bit/6-bit passcode. Apple doesn't claim that.
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.
>Hi oefra! Thanks for the feedback. We wanted to provide the same security pattern that iPhone's provide - 4 digit, 6 digit and alphanumeric.
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.
Hi gruez - we only store your passwords (encrypted) on your device. We don't store it on our servers. So anyone trying to hack should have physical access to your device to tamper with it. So basically they should be able to go through your iPhone passcode first even before they try to hack the app.
The security page [1] is extremely light on details. For example, sharing information with others usually involves asymmetric encryption (public/private key) such as RSA or elliptic curve cryptography. The security page doesn't mention it at all.
It doesn't help that the security page also mentions "Militray" grade encryption.
Hi pnutjam, this free version will always remain free. Unless you are sharing, the pictures you store are encrypted and stored on your own device (basically using your iCloud storage). That's why we don't incur a huge cost. However, we are planning to introduce premium features in the future including a cloud storage option for people who don't have enough disk space on their device.
Thanks for explaining. I'd suggest you add some sort of faq or something on your page for people who might be interested in this.
I, personally, don't use the apple ecosystem.
> I trust Spideroak because the are transparent and I know how they are making money.
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.
I wasn't discussing their major data service. I was discussing encryptr, which is a small service they are providing for free. It only stores text, so it's pretty light and I expect them to have few issues carrying the cost. I also expect them to give ample notice if they discontinue it or start charging.
I've not really delved into the password app space, as I was always put off by the concept of one person being the 'admin' and everyone else being 'users' with access.
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.
Are you talking about two-way sync? Currently, if I share a password with my wife, she can see it. If the password needs to be updated, I will update the password in the app, which will update the password on her app too. But I believe you want my wife to be able to update it too? Yea, we can maybe add that if that will help!
I'm saying exactly that. Password Apps should have an option for logins to be peers, not Primary and Secondaries. In well established relationships, it's not uncommon for logins to be shared between partners, or even to have full access to each others accounts. If the Netflix bill is paid out of the joint account (or shared bills account) why should I get to be the only one who can store/update the password in the app?
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.
Hi jedisct1! You should have seen our previous version of the landing page.. it had tons of security details but we got feedback that a normal user won't be able to understand it and it might overwhelm them at best. The feedback was that people might not want to use something that they don't understand. That's why we cut down on the security jargon and tried to keep it dead simple. But seems like a little bit more info might actually help based on the feedback here ha. So thanks for the feedback!
Yea we did move the details to the "Security" page now but we got feedback that even that was too much for a normal user. But I think having a link for "full details" might solve it.
Nice! My $0.02 is to consider all feedback, but it’s still up to you and what you know is best for your project to make the final calls. If people get to the “security technical details” page and say that it’s too technical.. well, not all feedback needs to be addressed :p
This app isn't for a security conscious person... they won't use it or pay for it, so I recommend them targetting the snapchat normies who'll get pwnt one way or another
Both of those cases are likely to occur with high possibilities. (poor security hygene, divorce, etc)
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)
Maybe the dude had a bad run in with divorce lawyers who, to put it lightly, can get everything and anything from you (and I do mean anything and everything).
It's not really a thing to insult someone over though.
It's about protecting your data. Disks are encrypted and keys are not stored. Only backups are available to my next of kin who isn't my wife for reasons I don't want to get into here :)
all the comments here are getting hung up on the encryption.
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.
Yea but you can also just use Open-Source bitwarden and either self-host, use free-tier for personal use or buy their service for 10$/year and it also enables sharing credentials.
Netflix yeah but how many bank passwords are going in there?
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.
Hi imglorp - we don't save your passwords on our servers when you save them. It is only stored on your own device, encrypted. If you choose not to share, it will never leave your phone. When sharing, we use end-to-end encryption. When sharing, we only store the encrypted version of the shared content until it is received by the recipient (or 30 days whichever comes first). This is similar to the technique WhatsApp follows.
I believe trying to mix up Passwords with others, such as Photos, isn't such a good idea. I like to think that Password management itself it a really big task on its own.
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.
Hi Brajeshwar, if you think about the whole password management suite that other popular password managers offer, yes it is a really big task in itself. However, SecureAppy focuses on the simpler use cases of just me letting my wife and kids know certain passwords and have them handy whenever they need them. We also made sharing photos/notes very easy so that your most important photos/notes are organized perfectly within the same app.
Fastest way to share, price and ease of use is what we see as differentiators. We wanted to make sharing stuff securely as simple as sharing a snap on snapchat!
A feature I'd really like to see on a password protected account or a sharing app would be a second password that works only after n days of no logins.
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.
No web/desktop? So if I'm sitting at my desk I have to manually type the password by copying from my phone screen? I think this is too much to ask of people, especially since we are (rightly) encouraging people to choose passwords like gwz8v8yHGg@P%G6t@WTsXcnV
llimos - you are right. It is not built for the use case where you are typing you password in continuously to login to normal web apps. As you already know, the browsers do a good job at that (if you trust them). We are going after the use case where you want to share passwords easily with family members, store desktop app passwords, as well as ability to store some of those sensitive passwords you do not wish to store in your browser.
Just a note: the phrase "military grade encryption" is so polluted that you probably want to remove it from marketing pages. I'm definitely not alone in thinking of cringey YouTube sponsor ads for VPNs at this point. That marketing copy actively makes me think the developers are incompetent, which I'm sure isn't what the marketing team intends.
I like this idea a lot because the use case pattern for families as an entity is unique and not as well served as it could be. Why should tech platforms have the entire history of your parents discussing your upbringing and every notable day in your life?
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.
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.
Thank you for your feedback newscracker. This free version will always remain free. Unless you are sharing, the passwords/notes/pictures you store are encrypted and stored on your own device (it uses your iCloud storage for backup if you have it on). That's why we don't incur a huge cost so we are able to keep this version free. However, we are planning to introduce premium features in the future so we follow a freemium business model. We will update the FAQs so it is more clear.
Still doesn't answer the open-source question, everything client-side should be open-source and showcase proper crypto implementations and assurance that credentials aren't just sent in plaintext to your servers.
Right from the start we have wanted to do a freemium model. Just wondering how we protect IP when the code is open-sourced especially when all the encryption is done on the client side. Also, is it a standard for security apps to be all open-source? For example WhatsApp messenger claims to do end-to-end encryption but they haven't open-sourced their software. Also, Last-Pass has a free version too but they have not open-sourced their code. Is open-source the only way to help users believe in the app? I know for highly technical users it may help. But for an average user who is non-technical and wants to use the app, would they even understand what open-source is? I personally don't think not having an open-source code base delegitimizes the app but happy to see what everyone else thinks.
96 comments
[ 3.7 ms ] story [ 149 ms ] threadhttps://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.
There is never a reason you'd want to store such sensitive data in cleartext.
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 :)
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.
It doesn't help that the security page also mentions "Militray" grade encryption.
[1] https://www.secureappy.com/security
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...
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.
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.
your better off , richer, freeier and more secure
No male can be totally free as long as women depand on the state
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.
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.
1. https://1password.com/families/
2. https://keepass.info
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.
You are probably thinkinng of "language" or "copy" :)
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.
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.