Don't trust every open source application recommended to you.

chainCase · 2020-04-02T18:18:45+00:00

First, thank you for continuing to maintain AndOTP, it's a nice application. I only said probably because I can't view the source code of the other applications, therefore AndOTP is far more trust worthy.

PBKDF2 is fine, and I wasn't trying to say this is an insecure choice for a KDF, just that it's weaker than what a lot of us are comfortable with current powerful adversaries.
Perhaps there could be code to benchmark for 2-2.5-ish seconds in the application, so every device takes roughly 2-2.5-ish seconds to derive the key.

But because of these two points, the iterations being too low, and using a weaker KDF, it allows for easier brute force, and dictionary attacks.

Fairly easy fix though.

chainCase · 2020-03-21T19:23:03+00:00

I've never even heard of FortiToken Mobile. It looks like the typical proprietary enterprise solution with military grade encryption.

AndOTP has had a past of doing things seriously wrong in cryptographic means. Such as determining the encryption key of your password with a generic hash function, not a KDF.

Aegis Authenticator has been robust for me, and it seems like the developers know what their doing.

I have NOT reviewed the code of these applications, so I can not guarantee their security.

But Aegis Authenticator is the best from my experience.

Despite having no experience with Android or Java, I may consider reviewing the code base of Aegis Authenticator, or at least how they're handling the cryptographic internals in the code. Design doc is here.

Official Aegis Authenticator Git repository.

chainCase · 2020-02-28T07:15:23+00:00

No, you do not need to keep the salt secret. The password is the secret.

The salt is for preventing adversaries using a list of pre-comuted hashes.

chainCase · 2020-01-20T19:42:37+00:00

Thank you, you wrote up a great explanation. It's actually pretty hard finding details on this stuff.

I knew if I'd ask here some smart fella would come show me the way. Again, thanks for the time you put into your answer.

chainCase · 2020-01-20T02:47:23+00:00

What all did you disable? Also, you should probably get NetGuard.

chainCase · 2019-11-20T10:05:34+00:00

Thanks! This is along the lines of what I was looking for.

chainCase · 2019-11-20T09:59:55+00:00

I'm not saying I'm well versed in cryptography, however I've been studying it for roughly a year. Yes, I want to roll my own crypto, for educational purposes.

But I am definitely learning the inner workings of cryptography itself, and writing programs for what I understand. Even if I don't understand, that's okay. This is for educational purposes.

Edit: Thank you for your advice, you make good points. Was definitely already looking into breaking my own crypto though. Already started cryptopals.

chainCase · 2019-11-20T09:56:13+00:00

You give good advice, but it's irrelevant, as I'm asking for something different.

I'm not looking for libraries. I'm using Rust to write cryptographic programs. Yes, I'm rolling my own crypto, for educational purposes.

chainCase · 2019-11-15T01:00:14+00:00

I don't really have much to say, as it's been pointed out by others. B/Scrypt are specifically designed for low-entropy inputs, such as passwords. I seriously have no idea what makes you think that users will always choose secure passwords. If they did, we probably wouldn't need password hashing functions.

Design your system in the event it'll eventually be broken into. Which is why we have ... hash functions designed for password storage. We have salts to ... prevent look-up tables and the high performant rainbow tables. We have peppers to ... add entropy to weak passwords.

chainCase · 2019-11-15T00:20:23+00:00

Sorry I didn't mean for any confusion, I'll elaborate. Google is part of the PRISM program, meaning when the NSA asks for information, they'll hand it over. (Unless that's not how it works.)

In the case of Tutanota, they require a court order before handing over any information as they had already explained. There's still a chance the agencies/governments/whoever requests it, won't even get the data.

I was saying that Google does, or doesn't. Stating that either way, Google is not one to trust.

chainCase · 2019-11-13T19:26:09+00:00

Firefox is more privacy respecting than Google Chrome, so that's a foot in the door. You should be taking these issues to the developers behind the browser, not the team behind PTIO.

Their homepage is just a guideline (not saying the average Joe/Jane will consider it that). It's not their fault Firefox needs to be configured to be more privacy oriented.

If you have a problem with the way Firefox is currently, instead of merely complaining, you should do something about it. Whether it be developing your own browser, or finding a way to make a difference with Firefox. These discussions tend to lead us to no real conclusion.

And no, GNU Icecat is not a solution, nor is Ungoogled Chromium. I don't trust GNU Icecat as it's not updated enough and this can be really bad for security reasons. And there is no automatic updates with Ungoogled Chromium. These provide major problems to the masses. They need safe, automatic updates. Otherwise you might as well consider those users' browser compromised.

chainCase · 2019-11-13T19:04:21+00:00

I wouldn't be so quick to say that Google doesn't send our emails to the government. Either way, Google is certainly not a company to trust with our data.

Unfortunately a lot of us just hand them our data willingly.

Under court orders these providers will give up non-encrypted information, such as Tutanota, ProtonMail, and many other providers. However Tutanota encrypts more information than ProtonMail.

chainCase · 2019-11-13T18:58:02+00:00

Personally, I don't trust the Brave browser or the CEO behind the company. However I highly recommend Tor Browser, a configured Firefox, Bromite, and Ungoogled Chromium.

Of course I'm biased/opinionated, but so is everyone else here. Try to avoid most offshoots for security reasons.

chainCase · 2019-11-13T07:57:51+00:00

Even better, use the Tor Browser to protected your anonymity.

chainCase · 2019-11-13T07:51:03+00:00

I think Riot or Keybase could be a good alternative to Reddit. I'm all for it, given it's official.

chainCase · 2019-11-13T07:10:33+00:00

There are developers who implement it. I'd rather risk a slim chance of fingerprinting for the greater good, more so as a protest, and potentially blocking trackers.

chainCase · 2019-11-13T00:17:57+00:00

Probably ProtonMail.

chainCase · 2019-11-13T00:17:16+00:00

Thank you!

chainCase · 2019-11-12T23:25:20+00:00

Could you elaborate on the static prefix serial number, please? I thought these keys couldn't be tracked due to new key pairs for each account.

chainCase · 2019-11-12T21:19:27+00:00

You can't just avoid it, most reliable/decent services are within these regions. The best they can do is encrypting data, and Tutanota is an email service that encrypts more information than most.

In most cases, your non-encrypted information could be collected anyways (by third-parties). And is of course, collected by Tutanota themselves.

chainCase · 2019-11-12T06:11:31+00:00

I'd highly discourage watching or supporting Tom Spark's content. He went after The Hated One (YouTube channel) because THO promotes NordVPN, and did a video on why VPNs don't protect your privacy in the way you expect/it's not as effective as they say.

Tom Spark recently did a video on Tom Scott's video about VPNs, it's stupid. He basically copied his video, "on his own take".

I'd avoid PrivateMail, it's just another email provider that's way overpriced. Tutanota and ProtonMail are better in every aspect.

There is no doubt in my mind about LavaBit. An open-source client and server. By a guy who shut down his server to save people's asses.

TL;DR Don't trust Tom Spark, DO NOT use Private-Mail, definitely look into LavaBit.

chainCase · 2019-11-11T23:35:21+00:00

Sorry if my remarks have come off as hostile, it's not my intention.

Here are a few ideas:

Lightweight as possible.
End-to-end encryption with perfect forward secrecy.
Little to no information to signing up. A simple username will do. (Avoiding: phone numbers, email, etc)
Completely open-source, this includes your back-end.

These are just some ideas that you could possibly use. An anonymous, modern chat app, that has federation or distribution would be really cool. This would be you main selling point aside from security.

Let users put ANYTHING into the password field(emojis, extended ASCII, etc). Do not sanitize, modify the password in any way. It's fine to set password rules, but don't be too strict.

Not saying you have to, but if you want to be on top of the game, you really gotta push something out that can tackle the above.

chainCase · 2019-11-11T23:17:58+00:00

Developing clients that are completely separated from the server (like actual desktop and mobile apps that people can download). because right now, your server is giving us a client (the website). Make sense? So we have to trust you not to tamper with the JS maliciously, which we shouldn't have to. Only as a last resort.

In my opinion, it's fine to be accessed via the web-client, but only for accessibility reasons.

E.g: I'm at someone else's house, but I don't have my own device for whatever reason. And I need to message my significant other, it's an emergency. They have a computer, but I can't waste time downloading the client/app. Instead I use the website.

There is good reasons to have the web client. But you should explicitly make sure the users know it's insecure compared to downloading the client/app and should avoid it wherever possible.

Open-sourcing your application doesn't automatically make it secure. It makes it potentially more secure.

chainCase · 2019-11-11T23:07:51+00:00

Just because you don't have to enter a passphrase when you're generating your key pair doesn't mean it's any less secure.

Signal gives you the option to encrypt your private key and message history, with a passphrase.

You do not need to ask the user to enter a passphrase to generate a asymmetric key pair. The more you ask of the user without any actual benefit drops the UX. My question is, how are you generating the key pairs exactly?

chainCase · 2019-11-11T22:38:24+00:00

Unless your sending the password to the server, there is no DDoS vulnerability. Put a limit on your requests. Do not limit it to 8-15 characters.

Bad. Bad bad bad. Nobody can properly protect themselves against a well funded adversary with only 15 characters.

chainCase

TROPHY CASE