the real content on google security is here
|
| Author | Content |
|---|---|
| mbaehrlxer Feb 17, 2017 6:21 AM EDT |
that article requires registration (though bugmenot works) and has little substance. it effectively just says that google took 5 years or so to switch from a network based system (everyone inside the network is trusted) to a device based system (only known devices are trusted, regardless of where they are in relation to the google network) the actual details of how this works are a usenix publication from 2014, which you can read here: https://static.googleusercontent.com/media/research.google.c... https://research.google.com/pubs/pub43231.html greetings, eMBee. |
| dotmatrix Feb 17, 2017 9:54 AM EDT |
Without reading the article... The Google device trust is based on the X509 certificates installed on each device. It's essentially the same as the 'client certificate' trust model. However... since Android malware is one of the fastest growing malware markets... I don't think they're doing so well in the 're-invented security' arena. |
| jdixon Feb 17, 2017 12:03 PM EDT |
> The Google device trust is based on the X509 certificates installed on each device. It's essentially the same as the 'client certificate' trust model. Sigh, wonderful. Now I actually have to read the article. :( Not today though, fighting off a nasty cold (unsuccessfully so far) at the moment. |
| dotmatrix Feb 17, 2017 12:45 PM EDT |
After briefly reading through the corporate network and resource authentication architecture...
Hope you feel better soon... if you're in the Northern Hemisphere, 'tis the season... if you're in the Southern Hemisphere, summer colds are no fun at all. |
| jdixon Feb 17, 2017 1:22 PM EDT |
> The architecture is based on 'client certs' -stored in a device TPM- and third party single sign on. Third party undoubtedly equates to proprietary in this case. :( So, is there an open source equivalent that uses ssh keys? Well, a quick search turned up this post: https://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys-... which lets the tpm handle the ssh keys for you. That's not a full solution, but it's a good start. |
| dotmatrix Feb 17, 2017 2:54 PM EDT |
>Third party undoubtedly equates to proprietary in this case. :( It's not proprietary in the sense of software or intellectual property. SSO software is mostly Open Source... I think it's mostly FOSS. However, the general idea is that an organization or a web service provider off loads authentication to a third party such as Facebook or Google. So... If you are signing in to your organization's web application, you sign in to Google first... Or your organization 'checks' with Google and then an authentication token gets exchanged between Google and your organization. Advocates of corporate single sign on through a third party authentication service justify the trust in the third party as 'off-loading risk.' The third party authenticator is accepting the 'risk' of authenticating rather than the organization itself. However, I tend to think this is more of an off-loading of legal and immediate financial risk in exchange of security and long term investment risk. In my mind, third party authentication increases security risk, because the organization's trust boundaries have been extended through an unknown and unknowable trust anchor and architecture. |
| flufferbeer Feb 18, 2017 2:15 AM EDT |
greetings right back at yer (just in case...) @dm, > However, the general idea is that an organization or a web service provider off loads authentication to a third party such as Facebook or Google. ... yeah, there certainly ARE those sheeple who'll always give their absolute completetrust to the likes of Facebook and/or to the almighty Google for their authenticatin :/ 2c |
| mbaehrlxer Feb 18, 2017 8:30 AM EDT |
this is something i am not really sure i understand fully. when you use a third party for authentication, in which direction does the trust flow? let's start with the assumption that all i care about is identity. my servers don't have private content. like LXER for example. all we care about is that when someone logs in the second time, they are the same person that logged in the first time. now assume that LXER trusts github to identify the user. so as long as github can assure LXER that the logged in user is the same as the one that was here yesterday, what is the risk? i see the following risks: * a github admin could impersonate a github user and gain access to the LXER user account. * github login could be insecure and someone else could gain access to the github user for the same effect. * LXER learns the github identities of its users and can use that knowledge for nefarious purposes. * does github learn the identities of all LXER users? * does github get permission/access to control the LXER account? (could github post messages on LXER on behalf of the user?) * does LXER get permission/access to control the github account? (could LXER make submissions on github on behalf of the user? i keep seeing this one when facebook or twitter is used to authenticate: "we promise we won't post any messages." that sounds very scary to me. is there no way to prevent that? greetings, eMBee. |
| dotmatrix Feb 18, 2017 11:00 AM EDT |
eMBee: Any web service would have the ability to post any messages of any sort to any account. So, having an admin impersonate a user is always a risk with any service an individual is using. One of my main concerns with third party authentication is referenced in your 4th point: >does github learn the identities of all LXER users? And the answer is: Yes. ***** The following are some of my personal concerns with third party authentication:
So, given the above, why would third party authentication be desirable? ... It saves money in the short term because the organization does not need to hire a network admin nor directly pay the bill for maintaining the user/password database. There is also a separate entity to blame if something goes wrong. This last point is also why many organizations use proprietary software. In my mind, the perceived benefits do not justify the actual costs. The third party authenticator will be compromised, it's only a matter of when, not if. And when it is compromised, your organization is very vulnerable to attack. Furthermore, even if you are lucky and not directly compromised, the organization is leaking very valuable information to the third party in an uncontrollable way. ****** I suppose if a given web forum which doesn't store too much personal information... email addresses are stored... passwords are stored... internal, non-public, messages are stored -even if rare- ... a third party authenticator may not be so bad. However, an account on the given authenticator service is still required. So, your user base -some of whom may not have nor wish to have an account on the authenticator- are now required to become members with usernames, passwords, and increased web presence. EDIT: Passwords and email addresses need not be stored if a third party authenticator is used. However, the other points still remain: ...private messages through the forum. ...external account required. ...user tracking on and off the platform. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!