Hi, great point. Currently, users have to use their phone numbers to login. However, user's phone number is encrypted in the db.
To ensure that everyone's comfortable with it, we're adding a new feature which doesn't require the user to login.
To ensure that everyone's comfortable with it, we're adding a new feature which doesn't require the user to login.
If you actually mean hashed using a one-way function, it would be very easy to hash every possible phone number (there are not that many) to build a lookup table to deanonymise your users instantly. Even if you individually salt each hash it would not take very long at all to find the phone number for each entry.
If you do mean encrypted, then authorities could compel you to turnover the database and the key.
Why do you need to store the phone number in any way at all?
> The newer version which won't need phone number to login is on its way.
So which is it? new features need the phone number but the new version won't require it? Are you gonna ask users for permission to use their phone number to access the new features? Will users who prefer their anonymity be able to interact with users who surrender their identification?
Isn't the unique token good enough?
You can't get around this problem unless you invent magic psychic computers. What is the point in finding every possible flaw with security here? There is a gradient of complexity, the time it takes to break these things. Currently, everything that exists is susceptible to being broken, misused, or modified.
If you assume that your attackers know everything, and have the ability to immediately find and apply that knowledge, then yes, it can seem scary. But I tend to think that the more capacity a person has to do, it's really just a bigger intellectual burden.
Because security is only as good as its weakest link, and an adversary who wants your sensitive data won't choose not to break in because your security is "mostly OK".
At the risk of being overly negative, if you have this attitude, you're not building a secure system, and, for your users' sakes, you shouldn't say that you are.
I agree that security should be taken seriously, with care and caution, and that users who ethically need to be aware of potentially fallacious assumptions about the usage of a device should have the capacity to easily find that information.
It's fine if you think this is an unreasonable conclusion to draw based on the evidence; you're entitled to your opinion. But the question is, do you feel comfortable with the possibility of people going to jail or dying because they didn't understand the security tradeoffs that this app makes? I think it's because some of us see this as an extremely real possibility -- particularly given the frankly ineffective security practices described here -- that you're seeing so much backlash.
The Burmeses government however is not likely to be able to perform something like this, especially if the authors are not in Myanmar. In fact, there's a reasonable chance that the authors of the software are CSOs sponsored by other governments that would like to see changes in the regime in Myanmar (like the CIA's ZunZuneo app in Cuba) - in this case it is not likely that the government there will be able to play effective whack-a-mole.
The danger here is that the government will ban phones or create some sort of licensing for them if this becomes a large enough civil unrest problem. But it's equally likely that other countries would then raise sanctions and human rights violations against the regime on account of principles of 'freedom'.
Some people think cryptography is this utterly complex thing sitting on the edge of understanding. It isn't.
Evidence of rolling your own crypto, authentication or key-exchange mechanism is the first thing an attacker you'd want to worry about will look for.
Developers design systems that are easy to break because of ignorance and hubris. That's not to say you can't learn how to implement a secure system, just that if you did any research, you'd know that Rolling Your Own Is Bad because proper design is Hard and people, with much more experience than you, are aware of choke points in your design that you aren't aware of.
Few algorithms are correct such that their computational complexity alone is what provides their security. Without a formal proof, an audit and some testimony of experts I will not believe your hand-rolled algorithm is correct.
This is why you rely on proven algorithms and implementations and never roll your own. But you should not believe that using a correct algorithm alone should be enough to deem a system secure.
Its implementation might be exploitable in a way that sidesteps the security provided by your algorithm.
The idea that it might take an attacker five billion years to brute force your cipher text for a solution is nice, but if you're exchanging keys in an insecure way then that security goes right out the window.
Storing your salt on the same DB? Your search time for a solution is cut down since you can grab that as well.
This is why emphasis is placed on tearing apart a system that claims it is secure. Most of the time it isn't, and usually in ways that are easily identifiable.
Having good faith in the developer isn't an ideal when the well-being of many people might be at stake because of claims that cannot be backed up.
1. Use a hashcash style proof of work mechanism to register account. The server send a challenge and have the client compute a nonce under the difficulty. This could be turned to take an average of seconds to minutes on your median users device.
This isn't a long term solution because eventually an attacker will realize that they can use more powerful machines to create sybils and abuse your network.
I'm actively working on alternatives ATM.
2. Embed Tor. The Guardian Project folks will be able to give advice on embedding a tor proxy in your app. There is documentation online as well. Chatsecure has done this.
This would reduce the amount of information you have in your possession for authorities to seize.
This would not protect your user base if authorities compel you to ship a malicious software update.
3. Also use SSL and pin your public key for your SSL cert
Blind signed auth tokens are way better but much more resource intensive to implement
But of course, this would most obviously involve a client-side component with access to system resources. Workable for a native android app, but perhaps not for desktop/browser...
http://www.networkworld.com/article/2876796/microsoft-subnet...
I think it solves your problem.
It's also outside of myanemar ,so it's helpful with regards to legal issues.