View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003649 | Composr | core | public | 2018-07-30 10:50 | 2024-07-25 21:33 |
| Reporter | Chris Graham | Assigned To | |||
| Severity | Feature-request | ||||
| Status | non-assigned | Resolution | open | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0003649: 2-step login | ||||
| Description | Allow login over 2 steps. The first step would be the username, the second the password. The username of an in-progress login would be stored in a new table that had the session ID, the username, and a login ID. That login ID would be presented on the second screen as a hidden field, and used for looking the username back up. | ||||
| Additional Information | This makes it harder for man-in-the-middle attacks, including malware running on a user's computer, from grabbing username and password combinations. | ||||
| Tags | Type: Security | ||||
| Time estimation (hours) | 5 | ||||
| Sponsorship open | 0 | ||||
|
|
I saw a good discussion about this. There are actually a few reasons sites are doing it... 1) Security, as described in this issue 2) Third party login integration, e.g. you put in your email and it realizes it is a FB login, or a corporate Okta login 3) Usability. No need for separate login/join/forgot-password links, as it can start the flow of all 3 by knowing what the email address is. |
|
|
Hmm, while I understand points 2 and 3, I'm not sure I understand point 1 as much. In my mind, I can only see it making man in the middle attacks harder to a small degree. A key-logger for instance would negate the protection, at least the way I'm thinking of it. |
|
|
I think I previously suggested an on-screen virtual keyboard, which I assumed may help prevent keylogging to some degree if used on the login screen and any other sensitive areas. The issue included a link to some opensource code (which I recall seemed pretty versatile in what you could do) but I have no idea how to search this tracker. There is this simpler version > https://github.com/quintanamo/virtual-keyboard and I'm sure there are others, or maybe the devs could create their own (mobile compatible) version. |
|
|
"I can only see it making man in the middle attacks harder to a small degree" - a small degree is something. If the information is in different response packets (MITM/captured attack), or different HTML pages (client-side attack), that must be re-aggregated that requires quite a lot more sophistication. |
|
|
"I think I previously suggested" - that would be 0003645. I'll comment on it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-07-30 10:50 | Chris Graham | New Issue | |
| 2018-07-30 10:50 | Chris Graham | Tag Attached: Type: Security | |
| 2023-09-12 01:15 | Chris Graham | Note Added: 0007995 | |
| 2023-10-01 03:18 | Patrick Schmalstig | Note Added: 0007998 | |
| 2023-12-10 16:18 | Chris Graham | Relationship added | related to 0003581 |
| 2023-12-10 21:24 | Adam Edington | Note Added: 0008118 | |
| 2023-12-10 21:29 | Adam Edington | Note Edited: 0008118 | |
| 2023-12-10 21:31 | Adam Edington | Note Edited: 0008118 | View Revisions |
| 2023-12-10 21:31 | Adam Edington | Note Revision Dropped: 8118: 0003818 | |
| 2024-07-25 21:23 | Chris Graham | Note Added: 0008950 | |
| 2024-07-25 21:32 | Chris Graham | Relationship added | related to 0003645 |
| 2024-07-25 21:33 | Chris Graham | Note Added: 0008951 |
