Services/Sync/Features/MigrateToDigestAuth
Status
| Migrate from Basic Auth | |
| Stage | Shelved |
| Status | In progress |
| Release target | TBD |
| Health | OK |
| Status note | ` |
Team
| Product manager | Jennifer Arguello |
| Directly Responsible Individual | Jennifer Arguello |
| Lead engineer | Chenxia Liu |
| Security lead | Brian Smith (?) |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | Tracy Walker |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
Open issues/risks
Sync web servers receive username/pass in cleartext (BasicAuth) through https before handing them off to LDAP/mySQL. Will be a problem when we store sync-keys protected by username/pass, because access to Sync web servers will be point of vulnerability.
If an attacker gains control of Sync web servers, they will have access to username/pass in cleartext, can use these credentials to access sync-key, and then unencrypt user data stored on Sync web servers.
Stage 1: Definition
1. Feature overview
Replace BasicAuth with more secure system where Sync web servers do not have access to cleartext passwords. This protocol can be DigestAuth, public/private key, etc, needs to be cleared with Security.
2. Users & use cases
Users using Sync will use more secure protocol (not BasicAuth) to authenticate access to Sync web servers. Passwords must not be passed around in plaintext.
Migration:
DigestAuth (strawman): will revert to BasicAuth once for calculating hash of password for authentication, and will use DigestAuth for all future authentication.
3. Dependencies
Must discuss replacement authentication protocol with security people (bsmith?)
4. Requirements
`
Non-goals
Hope to get ahead in setting up security necessary for running a sync-key server
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P2 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Sync |
| Secondary roadmap | ` |
| Feature list | Services |
| Project | ` |
| Engineering team | Sync |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | sec-review-unnecessary | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
