You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Iβve been thinking about ways to enhance security and protect user email addresses from bots and potential data leaks. Since we currently require users to register with their university email addresses, we can implement a mechanism to make this data harder for attackers to misuse.
π The Idea:
To protect email addresses:
Domain Verification during Registration:
When users sign up, weβll verify their email domain (e.g., .mit.edu) through the API to ensure they belong to a supported university.
The list of verified domains will not be stored in the database, but instead kept in a .env file. This means the domains will not be part of any potential data leaks, making it harder for attackers to determine valid domains.
Per-University API/Database:
Each university will have its own API or database to handle registrations. This ensures we can confidently validate domains and handle registrations specific to each institution.
By separating the API/Database per university, we add a layer of security and granularity to our approach.
π€ Considerations:
Scalability:
Managing a .env file for domains is straightforward for a few universities, but how do we handle it as more universities join?
Can we implement an admin interface to manage these domains securely in the future?
Data Separation:
With each university needing its own API/Database, weβll need a robust architecture to avoid complexity while maintaining security.
Should we develop a unified structure with isolated access for each university?
User Experience:
How can we keep the sign-up process smooth for users while ensuring robust domain verification?
Should we allow users to suggest their domain during registration (pending admin approval)?
π‘ Benefits:
Better Protection Against Data Leaks: Even in the case of a data breach, attackers wonβt easily deduce valid email domains or addresses since the domains are stored in a .env file, not the database.
Increased Security for Users: Adding domain verification ensures only authorized users can sign up while reducing exposure of sensitive email information.
Flexibility for Future Growth: By isolating APIs/Databases per university, we ensure a scalable approach to handle more institutions.
π Next Steps:
Feedback: What do you think of this idea? Are there better ways to secure user email data?
Technical Planning: How can we structure the API/Database setup to balance security, scalability, and ease of maintenance?
Implementation Plan: If everyone agrees, we can begin outlining a roadmap for this feature.
Letβs work together to keep SyncUp secure and user-friendly! π
complexity: complexTasks with unclear paths that need exploration or experimentation.priority: mediumImportant but not urgent tasks.type: securityIssues or improvements related to app security.special: scaling strategyPlanning or executing strategies for horizontal or vertical scaling.status: needs feedbackWaiting for input or feedback from stakeholders or contributors.type: ideaPlaceholder for brainstorming ideas or potential features.
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hey team! π
Iβve been thinking about ways to enhance security and protect user email addresses from bots and potential data leaks. Since we currently require users to register with their university email addresses, we can implement a mechanism to make this data harder for attackers to misuse.
π The Idea:
To protect email addresses:
Domain Verification during Registration:
.mit.edu) through the API to ensure they belong to a supported university..envfile. This means the domains will not be part of any potential data leaks, making it harder for attackers to determine valid domains.Per-University API/Database:
π€ Considerations:
Scalability:
.envfile for domains is straightforward for a few universities, but how do we handle it as more universities join?Data Separation:
User Experience:
π‘ Benefits:
.envfile, not the database.π Next Steps:
Letβs work together to keep SyncUp secure and user-friendly! π
Beta Was this translation helpful? Give feedback.
All reactions