-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make SnapPass safer #4
Conversation
RyanGWU82
commented
Jan 16, 2015
- Adds the prefix "snappass:" to all Redis interaction. If your Redis server is shared with other applications, this will prevent someone from using SnapPass to trawl your Redis database. This is backwards incompatible and will break existing links.
- Adds validation when accepting a key, to make sure it matches the expected 32 characters of hex.
- Adds validation when storing a password, to make sure the password isn't more than 1 MB. This will help prevent someone from using SnapPass to fill your Redis server's RAM (although it will only slow them down, not necessarily stop them).
1. Adds the prefix "snappass:" to all Redis interaction. If your Redis server is shared with other applications, this will prevent someone from using SnapPass to trawl your Redis database. *This is backwards incompatible and will break existing links.* 2. Adds validation when accepting a key, to make sure it matches the expected 32 characters of hex. 3. Adds validation when storing a password, to make sure the password isn't more than 1 MB. This will help prevent someone from using SnapPass to fill your Redis server's RAM (although it will only slow them down, not necessarily stop them).
I am concerning about the "backward incompatibility" regarding adding the "snappass" prefix. Could we add a release note section in the README to make sure the existing users aware of this. thanks! |
+1 on @yongwen 's comment. @RyanGWU82 first of all, thanks for the PR, I think it's a good idea. We can then set it to default to something reasonable like the Thanks! |
This thread seems to be dead. Unless @RyanGWU82 wants to rebase, we may want to close this, and create an issue for adding a prefix. We can then use that issue as a place to hold the discussion about maintaining backwards compatibility. Does this sound good to you @yongwen ? |
ok with me. thanks! On Thu, Oct 6, 2016 at 11:08 AM, Nicholas Charriere <
|
As explained above, closed in favor of #32 and will reopen with a clean rebase and a strategy for backwards compatibility. |