New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement some sort of "local developer account" login #150

Closed
kentonv opened this Issue Nov 3, 2014 · 6 comments

Comments

Projects
None yet
4 participants
@kentonv
Member

kentonv commented Nov 3, 2014

For the purpose of a localhost Sandstorm server that is only accessible to one person anyway and is intended only for development, it would make sense to implement some way to create test users and log in as them. This way, people don't have to hook Google or Github authentication just for their silly testing.

The feature should NOT use passwords or anything else that could be mistaken for security. The developer should be able to create as many users as they want and arbitrarily log in as any of them by just choosing the account from a list.

We can implement this pretty easily using the same approach as the "demo user" code.

@kentonv kentonv added the enhancement label Nov 3, 2014

@rpdillon

This comment has been minimized.

Show comment
Hide comment
@rpdillon

rpdillon Nov 7, 2014

I fired up a local dev server and was really surprised to see that I had to hook up to GitHub or Google. It seems strange to me, given the project's goals, that a fundamental feature like accounts is being handed off to the very companies producing products that Sandstorm is trying to supplant.

Are there any plans to create more federated mechanisms for account management?

Apologies if this should be a separate ticket!

rpdillon commented Nov 7, 2014

I fired up a local dev server and was really surprised to see that I had to hook up to GitHub or Google. It seems strange to me, given the project's goals, that a fundamental feature like accounts is being handed off to the very companies producing products that Sandstorm is trying to supplant.

Are there any plans to create more federated mechanisms for account management?

Apologies if this should be a separate ticket!

@kentonv

This comment has been minimized.

Show comment
Hide comment
@kentonv

kentonv Nov 7, 2014

Member

Hi Rick,

Here's the answer from the FAQ on our Indiegogo campaign (we should probably find a new home for this now that the campaign is over).

Why do I have to log in through Google or Github?

In short, because we actually think this is the most secure option we can provide right now, though we want to do better eventually.

Passwords have a lot of problems. People choose bad passwords. People -- even smart people -- are often fooled by well-crafted phishing attacks. And, of course, people regularly forget their passwords. In order to deal with these threats, we believe that any password-based login system for Sandstorm must, at the very least, support two-factor authentication and be backed by a human security team who can respond to hijackings. There must also be an automated password reset mechanism which must be well-designed and monitored to avoid attacks. Unfortunately, we don't have these things yet. Moreover, we don't believe that building a secure password login system is the best use of our time at this early stage.

Another problem with password login is that it makes federation more complicated. When you federate with your friend's server, how does it authenticate you? Not by password, obviously. Perhaps by OpenID or OAuth, but that is again a thing we would need to implement.

For now, by relying on Google and Github for login, we get top-notch security and straightforward federated authentication with very little work. This lets us stay focused on our core product. (We could add Twitter, Facebook, etc. login as well, but we are worried about people forgetting which one they used and ending up with multiple accounts.)

But we don't want things to stay this way forever. Eventually we'd like to support decentralized login mechanisms, like OpenID and cryptographic (PGP/GPG) login. These are stretch goals for us (see the "Goals" section, above), but of course we'll be happy to look at pull requests. :)

Member

kentonv commented Nov 7, 2014

Hi Rick,

Here's the answer from the FAQ on our Indiegogo campaign (we should probably find a new home for this now that the campaign is over).

Why do I have to log in through Google or Github?

In short, because we actually think this is the most secure option we can provide right now, though we want to do better eventually.

Passwords have a lot of problems. People choose bad passwords. People -- even smart people -- are often fooled by well-crafted phishing attacks. And, of course, people regularly forget their passwords. In order to deal with these threats, we believe that any password-based login system for Sandstorm must, at the very least, support two-factor authentication and be backed by a human security team who can respond to hijackings. There must also be an automated password reset mechanism which must be well-designed and monitored to avoid attacks. Unfortunately, we don't have these things yet. Moreover, we don't believe that building a secure password login system is the best use of our time at this early stage.

Another problem with password login is that it makes federation more complicated. When you federate with your friend's server, how does it authenticate you? Not by password, obviously. Perhaps by OpenID or OAuth, but that is again a thing we would need to implement.

For now, by relying on Google and Github for login, we get top-notch security and straightforward federated authentication with very little work. This lets us stay focused on our core product. (We could add Twitter, Facebook, etc. login as well, but we are worried about people forgetting which one they used and ending up with multiple accounts.)

But we don't want things to stay this way forever. Eventually we'd like to support decentralized login mechanisms, like OpenID and cryptographic (PGP/GPG) login. These are stretch goals for us (see the "Goals" section, above), but of course we'll be happy to look at pull requests. :)

@rpdillon

This comment has been minimized.

Show comment
Hide comment
@rpdillon

rpdillon Nov 7, 2014

I completely agree on the security front. I feel like I have a full-time hobby managing passwords and methods of 2FA. It seems like like a healthy compromise during this early development phase. I only heard about Sandstorm after the crowdfunding was over. I'll make a point to read the FAQ now.

I think it's important to move to something that doesn't rely on centralized authentication authority later. Persona and OpenID are both great options, but I'm really excited you mentioned the GPG-based option. =)

rpdillon commented Nov 7, 2014

I completely agree on the security front. I feel like I have a full-time hobby managing passwords and methods of 2FA. It seems like like a healthy compromise during this early development phase. I only heard about Sandstorm after the crowdfunding was over. I'll make a point to read the FAQ now.

I think it's important to move to something that doesn't rely on centralized authentication authority later. Persona and OpenID are both great options, but I'm really excited you mentioned the GPG-based option. =)

@timmolter

This comment has been minimized.

Show comment
Hide comment
@timmolter

timmolter Jan 6, 2015

Just to leave a note about the Google login setup, it failed for me, whereas the GitHub one worked.

It said Invalid redirect URL for a split second, and that was it. The redirectURL Sandstorm told me to use was: http://1.2.3.4:6080/_oauth/github (not the real IP address, but it was a raw one).

timmolter commented Jan 6, 2015

Just to leave a note about the Google login setup, it failed for me, whereas the GitHub one worked.

It said Invalid redirect URL for a split second, and that was it. The redirectURL Sandstorm told me to use was: http://1.2.3.4:6080/_oauth/github (not the real IP address, but it was a raw one).

@kentonv

This comment has been minimized.

Show comment
Hide comment
@kentonv

kentonv Jan 6, 2015

Member

The redirectURL Sandstorm told me to use was: http://1.2.3.4:6080/_oauth/github (not the real IP address, but it was a raw one).

Hmm, the redirect URL said "github" when you were trying to use google? Is it possible you copy/pasted the wrong thing somewhere? This is Meteor's login code which is pretty well-tested.

Member

kentonv commented Jan 6, 2015

The redirectURL Sandstorm told me to use was: http://1.2.3.4:6080/_oauth/github (not the real IP address, but it was a raw one).

Hmm, the redirect URL said "github" when you were trying to use google? Is it possible you copy/pasted the wrong thing somewhere? This is Meteor's login code which is pretty well-tested.

@timmolter

This comment has been minimized.

Show comment
Hide comment
@timmolter

timmolter Jan 6, 2015

Oh sorry, no it was a google URL, I copypasta-ed the wrong URL. But whatever was given by SandStorm to paste into redirectURL field on Google.

I suspect the problem is with the raw IP address. Perhaps Google's system expects a domain name.

Later on I needed to actually set the DNS settings on a real domain name to the server to get Media Goblin to work. Otherwise I was getting the problem described here: https://groups.google.com/forum/#!msg/sandstorm-dev/b6SAypu7U5I/lcN7G6ySCc8J

, in particular "Unable to resolve the server's DNS address." I guess because I was accessing the server with the direct raw IP address, which a DNS isn't needed for of course.

timmolter commented Jan 6, 2015

Oh sorry, no it was a google URL, I copypasta-ed the wrong URL. But whatever was given by SandStorm to paste into redirectURL field on Google.

I suspect the problem is with the raw IP address. Perhaps Google's system expects a domain name.

Later on I needed to actually set the DNS settings on a real domain name to the server to get Media Goblin to work. Otherwise I was getting the problem described here: https://groups.google.com/forum/#!msg/sandstorm-dev/b6SAypu7U5I/lcN7G6ySCc8J

, in particular "Unable to resolve the server's DNS address." I guess because I was accessing the server with the direct raw IP address, which a DNS isn't needed for of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment