On Mon, 2007-04-30 at 11:15 -0600, Devlin Daley wrote: > Username and password schemes do not give you that. Route Y > credentials don't prove you are who you say you are, they just say > that you in possession of a password for a given route y username.
Now we're moving beyond the scope of the problem at hand and into the realm of philosophy almost. Basically there are three things that, when combined, prove an identity: 1. Something you are 2. Something you know 3. Something you have Any company that has high-security access controls will have a system that requires the three things listed. For example, a memorized pass code, a smart card/RFid chip, and perhaps a thumbprint. In the normal world, though, a username/password combination has pretty much become the standard for proving identity, mainly because it is simple and effective. Giving one's username and password to another is tacit approval for another to do anything they want in his or her name. There is no legal mechanism for this, as in power of attorney, but most courts would likely find the owner somewhat culpable. Thus, to the point that I care, a username and password are enough to prove someone is who they say they are. > > The question of why was broader. Do you need to know they are BYU > students? or do you only need to know that they are the same person > you spoke to yesterday? Different light weight identity systems can > be used for some of these other scenarios, I was just wondering if > you were dealing with one of them. > > > The real question > > is, given that we don't totally trust the user, does the user trust > > us? > > A philosophical dilemma. Of course BYU students seem to pass their > > netid and password around like candy anyway, so maybe the question is > > moot. > > > >> > >> I dislike immensely providing that password to units other than the > >> actual Route Y. That situation easily lends itself to non authorized > >> impersonation. Is it absolutely necessary? > > > > Yes it is. > > > > I have to smile at your comment, as you've obviously not spent much > > time > > using BYU's various web resources. Kronos, Extensity, OIT's problem > > reporting system, blackboard. Everything requires a separate login > > using your netid and password. There is, essentially, no single > > sign-on > > on campus yet, despite site-minder. > > I have spent time using many of these web resources. This is why I > dislike "dispensing my password like candy" immensely. > > > > > How do you know that you are interacting with the official Route Y > > site > > anyway? The new web design puts a username and password field on > > *every* site, for *every* department, no matter where the page is > > hosted. There is now no longer any official Route Y unit that accepts > > your password. Topher recently discussed his spoofing research. The > > current BYU site is extremely vulnerable to spoofing/phishing. > > I agree: this is not as it should. I in no way tried to advocate > BYU's current implementations. > > BYU needs to eliminate the need for these disparate authentication > systems by making something that works and is light weight. > > > > >> > >> An easier method if you absolutely must: just attach directly to > >> BYU's LDAP. If you can login to the LDAP with their username/ > >> password, it's legit. Just disconnect when your done. > > > > If you'll reread my posts, you'll find the main reason for > > implementing > > this http hack is exactly because LDAP is not reliable on campus. > > LDAP > > is a secondary system for BYU, synced from other sources. I've worked > > with OIT on this issue and they basically say that there are sometimes > > password synchronization issues which they can solve on a per-user > > basis. This is not practical for us, though. I'm basically going to > > use this http login as a fall-back for LDAP. Any ldap bind that fails > > but http login succeeds will be noted and the netids passed on to OIT > > for analysis. > > Good to know. The bind to LDAP was suggested by a former OIT > developer a while back when I was working on a old project. Using the > http as a fallback looks like a nice way to handle the sync issues. > > > > >> > >> The University should really provide a mechanism so that the Route Y > >> credentials can be used around campus, without having everyone give > >> their password away. I think I've got a way around it -- hopefully > >> I'll get it implemented this summer. > > > > BYU's upcoming CAS will address this. Only one web site will ever > > take > > your password. It will grant you a ticket-granting cookie which your > > browser will pass to the various web sites that require > > authentication. > > This creates a very kerberos-like authentication system which works > > very > > well. We use CAS internally in our department for all our web > > authentication needs. In fact we're also looking at pam_cas, to allow > > our web-based e-mail client to use the CAS credentials, rather than > > require a username and password (which it currently needs for imap > > purposes). > > I need to look more into CAS. I saw it a while ago and had almost > forgotten about it. Your description of using cookies for a Kerberos > like system sounds very clever. A quick glance JA-SIG webpage shows > CAS as a protocol where you can have a number of possible back-end > authenticators (LDAP, active directory etc.) Which one are you using? > > > > > > By the way, anyone who is using LDAP binds as a method of > > authentication > > is abusing LDAP and needs to be hauled out and shot (don't look too > > closely at my use of ldap... :). LDAP is *not* an authentication > > method. LDAP can be used to provide information for *authorization*, > > but authentication comes from another source. > > Agreed. That's why I prefaced with "if you must". Taking passwords, > abusing LDAP, and screen scraping are all dirty and clear evidence > there should be something better. > > > Kerberos is likely the > > best place for it. Now if we had a full Kerberos architecture at BYU > > like MIT does, then everything from unix shell access to file > > sharing to > > web resources would all be done using kerberos credentials. > > Unfortunately that requires add-on software for almost all operating > > systems and even Firefox doesn't natively support kerberos. > >> > > I eluded to a project I was thinking of implementing to help the > situation. It's just OpenID for Route Y logins. > > Convincing BYU and OIT to build an OpenID provider and actually > getting it implemented is not realistic (already tried). > My plan was just to sidestep them. I want to build an OpenID server > that accepts Route Y credentials. I have to temporarily become a bad > man and take user's passwords and bind to LDAP or the HTTP method > (this is no worse than what is being done now). After that, anyone > (or any department) that wants to take Route Y credentials can just > use my OpenID server instead of processing the passwords themselves. > The hope is that after OIT and some influential people in the > university see how easy the solution was that the OpenID server will > just be transferred to the university's control. > > Adding OpenID login support to web applications is pretty > straightforward (and with lots of libraries). It's lightweight. It > solves a lot of the "give my password everywhere" problems. It > doesn't solve your authentication to IMAP scenario however. Perhaps > you could pull a similar maneuver with CAS. Instead of everyone > hosting their own CAS authenticating server, their application would > just consume the tokens and cookies your CAS server provides. > > -- Devlin > -------------------- > BYU Unix Users Group > http://uug.byu.edu/ > > The opinions expressed in this message are the responsibility of their > author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. > ___________________________________________________________________ > List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list > -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
