Auth

[cloudiirain]

Summary

We need to discuss and decide on what auth system to use.

Current Opinions

• @viggy96 suggested using Firebase, which as far as I understand is similar to OAuth. Firebase can use our data from third-party accounts (e.g. twitter), or it can handle storing the username and passwords for us.
• @GetRektByMe supports using external authentication providers (e.g. Firebase, OAuth), however he would like to also have our own native/local system for users who do not have a Twitter, Google Plus, etc. I think he mentioned something about 2-factor authentication.
• @scraeling thinks that we should not write our own auth system (if we use a native/local system). Using extensions like Flask-Login or Flask-Auth are preferred.
• My thoughts: I agree with with @GetRektByMe and @scraeling. While things like OAuth are nice, I think I have definitely met translators who strongly value their anonymity. I would personally never use social media to log into a translation website, and I would prefer to use a registration system. It matters to me less where the data is stored so long it is secure and we don't write it ourselves. As such, I think support for social media login (e.g. OAuth) should be put on the back-burner and take lower priority over something that supports standard username/password registration.

  Some Auth Extensions commonly used with Flask

• Flask-Auth
• Flask-Login
• Flask-Security
• Flask-OAuth
• Flask-OpenID
• Flask-Stormpath

(Note I haven't looked into most of these carefully. If you have existing experience with any of these, feedback is appreciated)

If you find blog articles or posts commenting on Flask auth, share them please!

• 2014: Stormpath says rolling your own auth is horrendous. Flask-Login is a good library but of course, they themselves (Flask-Stormpath) are the best.

[cloudiirain]

@SunDwarf has declared Flask-Security <3

I'm happy with that and so is @GetRektByMe

[viggy96]

Firebase also allows traditional username/password logins as well.

[viggy96]

That way we'd only have to store user tokens in the database, no matter the auth method used. Further, we'd only get access to the users information (e-mail) when we need it.

[viggy96]

So, even if the database is compromised, the attackers wouldn't even get a list of e-mails, just a bunch of tokens which would be pretty much impossible to de-hash.

[viggy96]

https://firebase.google.com/docs/auth/

[Fuyukai]

Yes, but then you have the issue of trusting anyone else with your security details (which is a big no)

[viggy96]

That's always an issue. One way, the users would have to trust us , and the other, trust Google And honestly I would trust Google with security details more than ourselves, because let's face it, if Google gets compromised, the world has much bigger issues. Also: https://www.youtube.com/watch?v=8ZtInClXe1Q

[viggy96]

We don't want to risk our user's private information getting compromised. In my opinion, NOT doing authentication ourselves is the best way to do that. And further, its not like Google is just storing a HashMap, of user auth data. All they're doing is hashing the data (and salting) we send them and comparing the hashes. With their vast amount of experience on the matter, I'm pretty sure Google would do a good job. And if you're worried about DMCA people knocking on Google's door, they would probably say, "we don't have that information" because they don't store that information in plain text, and the salted hashes can't be undone.

[Fuyukai]

In the end, you still have to send the data over the wire. Who knows if that's compromised or not?

It doesn't matter what company you use, you're still sending it to a third-party, which you don't have control over, or control over the intermeditary parties transmitting the data.

[viggy96]

Again, that is still an issue regardless. The user still has to send their password to us. However, the issue is the storage and actual authentication process. And there are not intermediary parties, just us and Google. If you don't trust TLS 1.2, we might as well give up.

For that matter, who knows if the user's machine is compromised or not, or the ISP is compromised or not? There are a dozen holes in authentication, I'm trying to solve just a few.

If we just DON'T store passwords and e-mails we can further protect the users' information.

[cloudiirain]

Saving both of these links for later reading.

I personally think both of you have valid points. I do think that using Firebase is more secure then storing data locally -- however, it's a business decision. Flask-Security should be secure enough for production, but how much more secure you want to be is a whole another question.

I'm going to start a branch with Flask-Security because the documentation is straightforward and Fuyu has experience in it (which is very valuable, by standards). ...also part of me just doesn't want to go through the process of making accounts and setting up data stores with Firebase. ;-; ...because laziness. :c (If we did end up going with Firebase, I think @viggy96 might need to do most of the setup since you seem to be familiar with it). Flask-Security is personally more familiar to me because most web frameworks have a similar extension.

[byronvanstien]

Decided on Flask-Security

[byronvanstien]

Switched to hashing with scrypt