for new users coming into PID-Gen what will we *require* users to do? will we force them into an option. for example lets say we offer SMS-OTP credit card or 3rd party email verification. do we present these three options and make the user provide data for one of them or do we also have the option to opt out of SS resets? i think if we do not force users to pick one they will choose 'none' or say "ill do it later" and not follow through. this would defeat the purpose since they will have to call in later anwyay
i think we need to force the users to pick an option in pidgen , provide the data (phone number CC# email etc), then later they can log into my-vt and opt out if they choose.
for SMS messages we need to provide some sort of anti-abuse controls. for many people txt messages cost money and you can put any phone number in that field and send unwanted texts to someone anonymously.
we could possibly extend the text of the message to include a link to report abuse. since it's an authenticated app we could log numbers used to make it traceable back tot he user.
wondering how e are implementing "Allow me to call 4Help to reset my password". if a user does not select this how does it appear in the DAT? will we simply have a warning flag indicating that the password is not to be reset, or should we lock out the interface entirely.
if we want to drive a hard line we should lock out the interface so a user can't get it reset by 'whining'. though we should maintain an override of some sort
Regarding the AuthMethodAnalysis document, the pros and cons of each method are presented well, but I'm not sure the audience (auditors, Jeb, etc.) who have not been involved in our discussions will know what you mean by "Remote Authentication." Please elaborate in the section title.
do we need a requirement to prevent brute force attempts on the password reset "log on".
i discussed with kevin options of only allowing so many attempts per session (like PIDGen), though you could write a script to make new sessions.
permanent or long term block outs leave users open to DoS attacks. one possible way would be to implement a sleep function curing submission. 3-5 seconds per submission would slow a brute force attempt to a crawl.
after furter discussion the best thing might be to put in a delay to slow down full random or shifting attacks then to only allow 5-10 log ons with 1 PID before requiring a captcha pass. this will mitigate the most dangerous attack (having the PID and brute forcing the ID number)
Kevin William Rooney, last updated by Anonymous on May 25, 2012
1 minute read
8 Comments
Doug Atwater
Jun 25, 2010for new users coming into PID-Gen what will we *require* users to do? will we force them into an option. for example lets say we offer SMS-OTP credit card or 3rd party email verification. do we present these three options and make the user provide data for one of them or do we also have the option to opt out of SS resets? i think if we do not force users to pick one they will choose 'none' or say "ill do it later" and not follow through. this would defeat the purpose since they will have to call in later anwyay
i think we need to force the users to pick an option in pidgen , provide the data (phone number CC# email etc), then later they can log into my-vt and opt out if they choose.
Doug Atwater
Aug 09, 2010for SMS messages we need to provide some sort of anti-abuse controls. for many people txt messages cost money and you can put any phone number in that field and send unwanted texts to someone anonymously.
we could possibly extend the text of the message to include a link to report abuse. since it's an authenticated app we could log numbers used to make it traceable back tot he user.
Doug Atwater
Aug 09, 2010wondering how e are implementing "Allow me to call 4Help to reset my password". if a user does not select this how does it appear in the DAT? will we simply have a warning flag indicating that the password is not to be reset, or should we lock out the interface entirely.
if we want to drive a hard line we should lock out the interface so a user can't get it reset by 'whining'. though we should maintain an override of some sort
Marc DeBonis
Oct 27, 201016b should actually be "Resource" accounts don't necessary have a PID correspondence. Sponsored accounts do.
Mary Dunker
Nov 01, 2010Regarding the AuthMethodAnalysis document, the pros and cons of each method are presented well, but I'm not sure the audience (auditors, Jeb, etc.) who have not been involved in our discussions will know what you mean by "Remote Authentication." Please elaborate in the section title.
Mary Dunker
Nov 01, 2010New names for SETI groups (stakeholders in the SRS document) are:
Enterprise Middleware& Authentication Services
Microsoft: Secure Infrastructure Services
Quality Assurance & Verification
Daniel W Fisher
Nov 03, 2010GR7 and GR8 are mutually exclusive based on the requirements of the password change project.
An account with an expired password will be in the locked state.
I would drop GR8 as password state is not currently well defined and ultimately account state is what matters.
Doug Atwater
Nov 12, 2010do we need a requirement to prevent brute force attempts on the password reset "log on".
i discussed with kevin options of only allowing so many attempts per session (like PIDGen), though you could write a script to make new sessions.
permanent or long term block outs leave users open to DoS attacks. one possible way would be to implement a sleep function curing submission. 3-5 seconds per submission would slow a brute force attempt to a crawl.
after furter discussion the best thing might be to put in a delay to slow down full random or shifting attacks then to only allow 5-10 log ons with 1 PID before requiring a captcha pass. this will mitigate the most dangerous attack (having the PID and brute forcing the ID number)