| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000057 | SKGB-intern | neues-kennwort | public | 2005-12-04 03:49 | 2017-09-12 21:31 | ||||
| Reporter | aj | ||||||||
| Assigned To | |||||||||
| Priority | normal | Severity | feature | Reproducibility | N/A | ||||
| Status | resolved | Resolution | won't fix | ||||||
| Projection | major rework | ETA | none | ||||||
| Platform | WWW | OS | iCab | OS Version | 3.0b | ||||
| Product Version | 1.0.1 | Product Build | |||||||
| Target Version | 2.0 | Fixed in Version | 2.0 | ||||||
| Summary | 0000057: Confirmation page on new password confirm | ||||||||
| Description | It'd be nice if people had the opportunity to review their action before their new password is set. A click onto the appropiate link in the email would then lead to a page with both a cancel button and a new password button. See the RISK digest mailing list's behaviour as an example (http://www.risks.org/). | ||||||||
| Additional Information | Security Considerations: Implementing would lessen the impact of storing the name/password combo in clear in pwtickets. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
aj (manager) 2017-09-12 21:31 |
As of 2.0 the new Access Code semantics no longer require a confirmation, making this issue moot. |
| Notes |