Login only with Gmail or Github Account ???

[collab...@gmail.com]

Hi,

I just want to take a look at the sandstorm vagrant vm - on localhost:6080 I am confronted with the Sandstorm app and on the right top corner there is a login link, which shows me two login options: gmail and github.

Well, at this point I had to laugh. Indieweb? Privacy? Yes, the main reasons I triy to investigate a little bit into sandstorm are, well, a little bit contradicted by the login options I am presented with.

Maybe the vagrant vm is somehow broken atm?

is it possible to use this with local accounts that are stored only inside the vm?

BTW: it would make sense to document on the startpage itself what exactly happens, when these login options are used - what kind of data is transmitted to which endpoint and what exactly is the privacy policy?

Another BTW: why are you using Google Groups? Are there no alternatives for a mailing list?


Thanks!

[Kenton Varda]

Hi there,

Below I've copied our FAQ answer about this from our Indiegogo campaign. The short answer is that as a paranoid security engineer, Google and Github are the only readily-available global authentication mechanisms that I trust. That said, we are interested in adding other options.

The only information transmitted to Google or Github is the fact that you logged into a server. The only information transmitted out of Google or Github to your Sandstorm server is your user ID and display name, which are only used for authentication. Your Sandstorm server does not transmit any of this information back to us.

We use Google Groups because it's easy to set up, it works (sort of), and I have experience with it. Once we have a good mailing list app on Sandstorm we'll move to that.

Let me know if you have any other questions.

-Kenton

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. :)

--
You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tiago Freitas]

I like the idea of SQRL. Have you read about it? I'm not a security expert but sounds good.

Something similar is being used now by the new WhatsApp Web.

- Tiago

[Kenton Varda]

Hmm... Unfortunately, it looks like SQRL is intentionally designed to give a different identity to every web site, which is contrary to our federated identity goal.

It also looks to me like there is no way to recover if you lose the device on which SQRL is installed, or if your private key stored on said device is leaked to attackers. Same problem as with GPG login. I'm OK with letting people use crypto login if they really understand the consequences, but we need to be careful about encouraging it to anyone else.

-Kenton

[Jon Spriggs]

On 4 February 2015 at 22:08, Kenton Varda <ken...@sandstorm.io> wrote:

Hmm... Unfortunately, it looks like SQRL is intentionally designed to give a different identity to every web site, which is contrary to our federated identity goal.

Could you not say "Login at your server: <url>" at which point you do an OAUTH dance, using SQRL as your authenticator? Or just login using SQRL and have a "Connect to your home server" button? All possibilities

 

It also looks to me like there is no way to recover if you lose the device on which SQRL is installed

You're encouraged (at least on the Android version I'm using) to store a backup key in paper (QR Code) format. Also, if you have a trusted desktop and a trusted mobile device, to have the same key on both. That way you "should" never be in the position where you are unable to recover... in theory!

 

or if your private key stored on said device is leaked to attackers

There's a revocation model built into the protocol ("I no longer control that key, upgrade from that key to this key for every subsequent authentication, authenticated with *this* upgrade process") - again built into the initialization.

 

Frankly, I look forward to SQRL becoming a major, if not dominant, authentication system.

--
Jon "The Nice Guy" Spriggs

[Karma Kolabor]

Hi,

​
thank you very much for the detailed explanation, I do understand the complications with building a login system much better now and I think it is a good idea to focus on the main product. But I am also very sure, that the user group that might be interested in a more decentralized infrastructure will be very concerned about these things and it will be very important to document the transmitted data very precisely, so they know what happens.

I have one more technical question: from what I understand Google and/or Github can see *which* server a user is authenticating to, so they know, ah, ok, user xyz is an authenticated user of a system with the ip address a.b.c.d - is this right?

From a non-tec perspective I see a big marketing problem here. Telling people "use your own independent servers, but you need a google account for it" is a message with a strong contradiction - for the masses that do not care about this, they will not care about sandstorm too, but the few that care for privacy and understand why a decentralized infrastructure might be important will identify the need of a google account as a no-go.

I tried to explain a few (non-tec) people what sandstorm brings - every body liked the idea of "my own server" very much, but also everybody stopped at the point of "google account required".

I am sure this has been discussed somewhere already, but I could not find it, so sorry when I recycle things that I missed. I just want to resolve that screaming contradiction I see here - maybe I am misunderstanding the sandstorm features in terms of "enable a more independent and private internet"?

Thanks again for your attention and patience,

Karma

[Kenton Varda]

Hi Karma,

Yes, Google or Github can potentially see which server you are authenticating with.

I understand that it's important to have other options and we are working on it.

-Kenton

[hitc...@gmail.com]

Just wanted to add a +1

I was hoping sandstorm would be fit for my use case, where I need to share a variety of app instances to clients and absolutely cannot rely on a 3rd party login system - in some cases it may be on a completely offline network.

Seems like Meteor accounts would be the obvious choice here? I'm a Meteor dev myself I feel I could contribute to some of the less technical aspects. In my particular case I'd need to implement a different login user experience; think acconts-entry rather than loginButtons.

Thanks!

[Kenton Varda]

Hey all,

As of Monday's push (which everyone should have by now, if you have auto-updates enabled), we now have the option to log in using a generic e-mail account, verified by sending an e-mail. You can enable this via the admin settings page, at the bottom of the sidebar.

Two caveats:

- You must have a working SMTP server configured.

- Currently, you have to log in as an admin to get to the admin page in order to enable email login, which implies that the admin cannot use email login. We plan to fix this soon.

You'll notice that this system doesn't use passwords. Almost all password-based login systems let you reset the password if you can receive mail to the associated e-mail address. We believe that by not having a password and instead going through an e-mail exchange for every login, our approach is strictly more secure, albeit somewhat less convenient. For now, I feel this is good enough to satisfy my security concerns with password login, although admittedly email has some serious security issues of its own. I still recommend Google or Github login (with 2-factor enabled) for anyone who cares deeply about security.

Thanks to Jason for implementing this.

Try it out and let us know what you think.

-Kenton

[Karma Kolabor]

G-R-E-A-T! Thanks, man, this is awesome!

[joni.k...@gmail.com]

I have problem, I do not receive activation code by e-mail,
no error messahes!!!

Anyway, ldap is most versalite way to manage multiple
application's usage rights and kerberos to create
passworldless access.

By lapd there is no need to create separate user database whit
managment tool's !

Google has also own application for android to be used to crrate one time logging based time.

Antway is I start to use any sandstrom depend application:
-must work whitout network connection
-must be working whit ldap, all others work's ldap !

Now I can not get login due password dose not come to box,...
..., smtp server dose not hear it!

I have used serveral legal combinations whit and whitout username password
dns ip,...

Not sending neighter no error message!!

[Jake Weisz]

As Sandstorm.io wants to support businesses, I would imagine LDAP support is only a matter of time. (I am eagerly awaiting such a thing as well.)

I haven't investigated using the email token login internally with our mail server, but I am guessing that is what you're trying to do?

[Jason Paryani]

Can you take a look at your sandstorm.log (usually available at /opt/sandstorm/var/log/sandstorm.log) and let me know if you see anything out of the ordinary? If your SMTP_URL is misconfigured, it could be dumping error messages to the log instead. There may be compromising information in there, so you may want to scrub your data before posting it here, or if you're not comfortable doing that, feel free to take this discussion off list.

-Jason

[Noah O'Donoghue]

I 2nd the request for SQRL.

I just moved to China, and it's amazing, it's a totally post-password world over here. Everyone logs onto social media sites (QQ, Wechat, etc) using a QR code scanned by your mobile phone. You can pay for good using the same method, but that's another story.

I'm spending a lot of time in Internet Cafe's now, and it's totally amazing to be able to logon to sites without giving them a form of authentication that can be cloned for a second logon. With a lot of the sites, you can remotely log off, using your phone too.

Anyone curious in seeing how this works, sign up for a free Wechat account on your phone and try logging on to the Mac/PC client. It's very cool.

[Alexander Kulbartsch]

I fully understand that you want to avoid the trouble of password handling in sandstorm. I think that SQRL can make it really easy to be implemented in Sandstorm as another, additional login option.

And of course, people using Sandstorm, probably want to be independent from the big internet players like Google or GitHub. And, as already mentioned, sending a login token by email is not a very secure way. So here I see a valid option for SQRL.

Of course, using SQRL requires you to take care of the master password and making backups of it, but I believe the people who care about their privacy (and presumably this guys here do) will care about their keys when using SQRL.

So what is your point on a federated identity? With SQRL I just have one identity (my master key). The login to a site is just one click away (depending on my paranoia ;-) ). But different web service can't join and identify me as the same person - what I realize to be a feature.

Anyway, logging in via Google and GitHub is still a feature. People may decide them self.

Maybe I could have convinced you to have a second look at SQRL?

An actual Podcast where Steve Gibson explains about SQRL:

https://twit.tv/shows/security-now/episodes/562?autostart=false

start at time 1:04:45

A visualy more appealing site on explaining SQRL: http://sqrl.pl/guide/

And the main page: https://www.grc.com/sqrl/sqrl.htm

Best regards

              Alexander