Comments on: Establishing and Securing Identity in a Distributed World http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/ Comic book guy, tech geek, and father of two... Sat, 19 May 2012 11:01:37 +0000 hourly 1 http://wordpress.org/?v=3.1 By: Effects of alcoholism and paxil xanax. http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-111735 Effects of alcoholism and paxil xanax. Mon, 02 Apr 2007 11:39:21 +0000 http://nosheep.net/?p=87#comment-111735 <strong>Effects of alcoholism and paxil xanax....</strong> Effects of alcoholism and paxil xanax.... Effects of alcoholism and paxil xanax….

Effects of alcoholism and paxil xanax….

]]> By: NoSheep! » NERCOMP: Identity Management SIG http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-146 NoSheep! » NERCOMP: Identity Management SIG Wed, 28 Sep 2005 01:45:34 +0000 http://nosheep.net/?p=87#comment-146 [...] In the final time slot was a general group discussion. I took this opportunity to ask how schools are establishing and maintaining credentials remotely. No one had an answer that was ideal, I suggested our current proposal and no one seemed to have any criticisms. One person suggested that maybe we don’t need to have as secure a system as we’re proposing to merely secure someone’s email. My reply to this was in a federated world with connections to the federal PKI bridge, InCommon services, and more, we are securing far more than email. It is our responsibility to have as high a level of assurance as possible. [...] [...] In the final time slot was a general group discussion. I took this opportunity to ask how schools are establishing and maintaining credentials remotely. No one had an answer that was ideal, I suggested our current proposal and no one seemed to have any criticisms. One person suggested that maybe we don’t need to have as secure a system as we’re proposing to merely secure someone’s email. My reply to this was in a federated world with connections to the federal PKI bridge, InCommon services, and more, we are securing far more than email. It is our responsibility to have as high a level of assurance as possible. [...]

]]> By: Casey http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-111 Casey Thu, 08 Sep 2005 20:18:53 +0000 http://nosheep.net/?p=87#comment-111 Whatever solution we choose, it will likely be better and quicker than the "show us that you're receiving a utility bill in our town to prove that you're a resident" baloney that goes on all over New Hampshire. Whatever solution we choose, it will likely be better and quicker than the “show us that you’re receiving a utility bill in our town to prove that you’re a resident” baloney that goes on all over New Hampshire.

]]> By: zbtirrell http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-110 zbtirrell Thu, 08 Sep 2005 19:52:48 +0000 http://nosheep.net/?p=87#comment-110 Fred - I love the idea of sending username and PCAC seperately. This helps to assure intercepts will not cause a security problem. Brendon - There are 2 major forces driving the need for this change. First, in our current system we have to have the SSN to generate the password and let users know what the password is, this isn't legal, so must change. In fact we have already started making numerous exceptions, and in turn these are cumbersome to support and time consuming to maintain. Second, as we look more at federated identity management, we need a secure industry accepted method of establishing and maintaining identity, ours currently would not be acceptable. Fred – I love the idea of sending username and PCAC seperately. This helps to assure intercepts will not cause a security problem.
Brendon – There are 2 major forces driving the need for this change. First, in our current system we have to have the SSN to generate the password and let users know what the password is, this isn’t legal, so must change. In fact we have already started making numerous exceptions, and in turn these are cumbersome to support and time consuming to maintain. Second, as we look more at federated identity management, we need a secure industry accepted method of establishing and maintaining identity, ours currently would not be acceptable.

]]> By: bhoch http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-109 bhoch Thu, 08 Sep 2005 19:50:45 +0000 http://nosheep.net/?p=87#comment-109 I agree the plan looks like a bear of an undertaking and I wonder if there are more worthwhile IT projects to complete on campus (a consolidated place to obtain computer help for users & sysadmins for starters). How many email accounts have been comprimised as a result of SSNs being stolen (or vice versa?) I think this plan might cause more confusion among users and the number of users whose identities would be "saved" by this would be minimal. I would prefer to see increased usage of the student IDs (generated by PSU randomly*) and decreased usage of SSN across campus. For example, a user may not obtain an email account without first having a student ID # (ideally a card too). The student number should be used in the account/password creation process, NOT the SSN as is currently the case. Anytime I see an SSN on campus, I ask myself, why an SSN and not a student or employee ID? Some campus depts obviously need it (HR, Financial Aid), but can they be more properly cared for? Does HR really need to ask for an SSN on the job application, or can it be ascertained after the indivdual has been hired? I was able to obtain 3-4 SSNs just by looking at faculty candidate folder in our office this past year! The big question goes beyond ITS and really is geared more towards indivdual departments who do use SSNs. There's some social engineering that needs to happen here, and I believe that some of that burden must fall on campus entities other than ITS. That's my 2 cents. You guys are on the front lines of all this, though, so you may have a different perspective. It's a tough problem no matter how you slice it. Let me know if I can provide more feedback. Good luck! Brendon * PS: Not sure if "student ID" is the same as "Banner ID" is the same as "Employee ID", but I'm simply refering to an internally generated random alphanumeric number. I agree the plan looks like a bear of an undertaking and I wonder if there are more worthwhile IT projects to complete on campus (a consolidated place to obtain computer help for users & sysadmins for starters). How many email accounts have been comprimised as a result of SSNs being stolen (or vice versa?) I think this plan might cause more confusion among users and the number of users whose identities would be “saved” by this would be minimal. I would prefer to see increased usage of the student IDs (generated by PSU randomly*) and decreased usage of SSN across campus. For example, a user may not obtain an email account without first having a student ID # (ideally a card too). The student number should be used in the account/password creation process, NOT the SSN as is currently the case.

Anytime I see an SSN on campus, I ask myself, why an SSN and not a student or employee ID? Some campus depts obviously need it (HR, Financial Aid), but can they be more properly cared for? Does HR really need to ask for an SSN on the job application, or can it be ascertained after the indivdual has been hired? I was able to obtain 3-4 SSNs just by looking at faculty candidate folder in our office this past year! The big question goes beyond ITS and really is geared more towards indivdual departments who do use SSNs. There’s some social engineering that needs to happen here, and I believe that some of that burden must fall on campus entities other than ITS.

That’s my 2 cents. You guys are on the front lines of all this, though, so you may have a different perspective. It’s a tough problem no matter how you slice it. Let me know if I can provide more feedback.

Good luck!

Brendon

* PS: Not sure if “student ID” is the same as “Banner ID” is the same as “Employee ID”, but I’m simply refering to an internally generated random alphanumeric number.

]]> By: fportnoy http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-108 fportnoy Thu, 08 Sep 2005 19:49:41 +0000 http://nosheep.net/?p=87#comment-108 Seems plausible on the "face" of it ..... but maybe the username and the PCAC should not be distributed together, but kept seperate, as banks do when mailing out the ATM card and the PIN. Seems plausible on the “face” of it ….. but maybe the username and the PCAC should not be distributed together, but kept seperate, as banks do when mailing out the ATM card and the PIN.

]]> By: al http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-107 al Thu, 08 Sep 2005 18:49:31 +0000 http://nosheep.net/?p=87#comment-107 Regarding the lag of having to snail mail another pcac to the user should they lose it ... Unfortunately email is inherently insecure and very easy to spoof, but what about a fax process similar to what network solutions does? Domain registrars have much the same problems as you're looking at here, with the exception that they never see anyone face to face, yet people are always trying to hijack domains. If you're not familiar with netsol, here's how it works: If you lose your password, and your email has changed so that you can no longer use a forgot password link to have your password emailed to you, you can fill out a form on their website with your information, then print that form, attach a copy of your driver's license, and then fax it in. In this case should a user forget their password and lose their PCAC, they could fax in a new request for a pcac with a copy of their photo id along with the email they want their new pcac sent to. Turn around time should be very low .... if you don't include a username with the pcac in the email, then anyone who happens to intercept the email or get it through an error in the email address will find a pile of letters that won't get them anything without the username. Just a thought. Regarding the lag of having to snail mail another pcac to the user should they lose it … Unfortunately email is inherently insecure and very easy to spoof, but what about a fax process similar to what network solutions does? Domain registrars have much the same problems as you’re looking at here, with the exception that they never see anyone face to face, yet people are always trying to hijack domains.

If you’re not familiar with netsol, here’s how it works: If you lose your password, and your email has changed so that you can no longer use a forgot password link to have your password emailed to you, you can fill out a form on their website with your information, then print that form, attach a copy of your driver’s license, and then fax it in. In this case should a user forget their password and lose their PCAC, they could fax in a new request for a pcac with a copy of their photo id along with the email they want their new pcac sent to. Turn around time should be very low …. if you don’t include a username with the pcac in the email, then anyone who happens to intercept the email or get it through an error in the email address will find a pile of letters that won’t get them anything without the username. Just a thought.

]]> By: Erich http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-104 Erich Thu, 08 Sep 2005 12:22:41 +0000 http://nosheep.net/?p=87#comment-104 1. I agree that 32 chars is a proper (and standard) length for the PCAC, or any other token scheme that you decide to use. 2. One of the benefits of using a PCAC or token to provide temporary authentication is that you could embed the code in a URL and present that URL to the user, which would bring them to a password change form online. Unfortunately, this would kind of require that the user already has an email address that could be used to send the PCAC to. Perhaps there could be two methods - email and snail mail and let the user choose how to receive the PCAC. Otherwise, I would be concerned about snailmailing this stuff and the time lags there. 3. The other concern is that a PCAC is tough to enter manually, and may scare users off. Then again, it's no worse than manually entering Micro$oft license codes... 4. Is there a benefit to keeping the PCAC valid after a password has been changed? If it is still valid, there is a small security risk there by having a backdoor. In the event of a lost password, should you just send a new PCAC? 1. I agree that 32 chars is a proper (and standard) length for the PCAC, or any other token scheme that you decide to use.

2. One of the benefits of using a PCAC or token to provide temporary authentication is that you could embed the code in a URL and present that URL to the user, which would bring them to a password change form online. Unfortunately, this would kind of require that the user already has an email address that could be used to send the PCAC to. Perhaps there could be two methods – email and snail mail and let the user choose how to receive the PCAC. Otherwise, I would be concerned about snailmailing this stuff and the time lags there.

3. The other concern is that a PCAC is tough to enter manually, and may scare users off. Then again, it’s no worse than manually entering Micro$oft license codes…

4. Is there a benefit to keeping the PCAC valid after a password has been changed? If it is still valid, there is a small security risk there by having a backdoor. In the event of a lost password, should you just send a new PCAC?

]]> By: zbtirrell http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-103 zbtirrell Wed, 07 Sep 2005 22:05:03 +0000 http://nosheep.net/?p=87#comment-103 My responses to DW: 1) 32 characters is pretty standard for product codes and things, also would allow us to simply generate and store an MD5 for the user. Also, we don't want users or even casual observers to remember or simply memorize this code. 2) for now we're saying set their password, their username would be preset. But, this would obviously be easy enough to go one way or the other on. 3) If a user forgets their username and password, AND loses the PCAC, the accountability is clearly on their end. That said, it is clearly a problem wiht distance ed to have any kind of lag. What other solution would allow for quicker re-entry than PCAC? Right now I can't think of anything that would be both secure and at all faster... I'd love to entertain ideas here if anyone has a solution. 4) intermediary step... hmm, not really, our structure isn't radically different than this now, so we're sort of at an intermediary. I have a flowchart of the current process and you can see this is true. (I didn't really want to share that sad/scary process with the world) As this is on the Internet... I hope other non-ITS people can be pointed here and review this. I welcome comments from the world. My responses to DW:
1) 32 characters is pretty standard for product codes and things, also would allow us to simply generate and store an MD5 for the user. Also, we don’t want users or even casual observers to remember or simply memorize this code.

2) for now we’re saying set their password, their username would be preset. But, this would obviously be easy enough to go one way or the other on.

3) If a user forgets their username and password, AND loses the PCAC, the accountability is clearly on their end. That said, it is clearly a problem wiht distance ed to have any kind of lag. What other solution would allow for quicker re-entry than PCAC? Right now I can’t think of anything that would be both secure and at all faster… I’d love to entertain ideas here if anyone has a solution.

4) intermediary step… hmm, not really, our structure isn’t radically different than this now, so we’re sort of at an intermediary. I have a flowchart of the current process and you can see this is true. (I didn’t really want to share that sad/scary process with the world)

As this is on the Internet… I hope other non-ITS people can be pointed here and review this. I welcome comments from the world.

]]> By: Dw http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-102 Dw Wed, 07 Sep 2005 21:12:31 +0000 http://nosheep.net/?p=87#comment-102 This is an interesting solution. I like the self-service aspect, along with the personal accountability. Here are questions and comments that come to mind. 1. Why 32 characters...that's rather long, isn't it. I assume it is a standard. 2. So once the user logs in with their new PCAC, they can immediately reset their username and password. Cool. 3. If they forget their username and password, and forget where they put the darned PCAC, or they are away from it, they have to show up to Library (HD next year) to get a reset or wait for snail mail. The accountability factor is good, the time delay on service may not be acceptable. Case in point: Grad student working from a distance. 2-3 days for mail is going to be a problem. The more online we go, the more this will impact us. 4. Can we have an intermediary step? Let's keep rolling this around, not a bad idea. We might want to talk to some non-ITS folks. Let a lay person respond to it. This is an interesting solution. I like the self-service aspect, along with the personal accountability.

Here are questions and comments that come to mind.

1. Why 32 characters…that’s rather long, isn’t it. I assume it is a standard.

2. So once the user logs in with their new PCAC, they can immediately reset their username and password. Cool.

3. If they forget their username and password, and forget where they put the darned PCAC, or they are away from it, they have to show up to Library (HD next year) to get a reset or wait for snail mail. The accountability factor is good, the time delay on service may not be acceptable. Case in point: Grad student working from a distance. 2-3 days for mail is going to be a problem. The more online we go, the more this will impact us.

4. Can we have an intermediary step?

Let’s keep rolling this around, not a bad idea.

We might want to talk to some non-ITS folks. Let a lay person respond to it.

]]> By: Life After Coffee » Password Management in an Identity-Theft World http://nosheep.net/story/establishing-and-securing-identity-in-a-distributed-world/comment-page-1/#comment-87 Life After Coffee » Password Management in an Identity-Theft World Fri, 02 Sep 2005 17:55:14 +0000 http://nosheep.net/?p=87#comment-87 [...] To read more about our procedure, check out Zach Tirrell’s post about this procedure on his blog.   [...] [...] To read more about our procedure, check out Zach Tirrell’s post about this procedure on his blog.   [...]

]]>