[Turn]http://www.zhihu.com/question/20218136/answer/16246633
1. The user can basically complete the automatic landing process.
Restart the client/browser, do not need to enter a password to login
You can still log in automatically after restarting your device.
2. User change network environment automatic landing effective
The same device with wired network, wireless network, temporary interrupt network does not affect the logic of rule 1
* Higher safety factor business may have an auto-evolved whitelist for IP, when rule 2 is restricted
3. The user changes the password after the original automatic login failure (including and not limited to the local automatic login)
Ensure that information that has been stolen/logged in on other machines can be "lost" remotely
4. Can cancel
User's Logout (explicit logout) operation invalidates the original automatic login (including and not limited to the automatic login of the machine)
And can turn off automatic login/Remember Password
Reinstall the SOFTWARE/client must be invalid (otherwise your phone uninstalled mo Mo, home wife Reload once can automatically landing, the consequences on ...)
and then there's the security layer.
5. Irreversible (for local token/bills/certifications)
Token (theoretical level) does not reverse the information except the user ID, including not limited to the account, password, login IP
6. No guesswork/collisions
Simple test: When there is a 100w valid token, a random generation of 1w tokens within the token range cannot collide
Why a 1w? Because token verification is a requirement for network overhead. When there are 1w dense requests in a short period of time if you do not find the attack, it can only indicate that your system monitoring is too poor (even the traffic map on the cusp)
7. Timeliness
Token may not be available for a long time, otherwise rule 6 will expire within a foreseeable timeframe
Recommended for no more than 1 months (now mostly 1 weeks). Specifically, you can refer to the design of each site
If you need a long-term reservation, you can continue the automatic login by changing the ticket (reissue new token).
8. Cannot be intercepted and stolen *
If the current network is a non-secure channel, the message can be monitored. Listeners stealing tokens cannot be used. Or the listener cannot steal tokens (no specific tokens can be parsed from the network packet). Simply put, the use of HTTPS protocol can quickly and transparently solve the problem.
Here are a few simplified versions, built on the premise that hackers do not deliberately attack the service to achieve basic protection. The threshold for such misappropriation is increased to the threshold height at which cryptographic code is obtained and decrypted.
Standard Edition: Common IP Whitelist
The high-level situation of rule 2 can also play a limited role, but it cannot withstand attacks on large regional networks (corporate networks, school networks, cell networks).
Cheap version (HTTPS is for money): Token has timestamp information encryption. That is, the token at the communication level changes every time.
Can be achieved by shielding public WiFi such as real-time comprehensive intercept attack situation
Minimalist version: Tokens are changed once every 5min.
When a non-exhaustive packet is reached (such as a temporary ARP attack on a local area network), token is sent to the attacker's mailbox and is exploited to attack at some point in the future.
Suggestions
Rule 1~4 is the most basic, can not be achieved at all not the standard
For services that do not yet have significant benefits, it is sufficient to complete the 1~6. Belong to a passing state. If the attacker does not attack, the service can be said to be "absolutely safe."
Conversely, even rule 8 has to be completed. Be in good condition
Ultimate Rule 9
Security defenses at the social engineering level. (deal with all known Software/framework/protocol vulnerabilities that you will know)
Reaching this level must be a service offered by a company that can be listed (or has the power to sell itself). When a master on the network obtains the token information or even the password directly through special means (such as the recent Heartbleed vulnerability), it is possible to get the help and support of white hat (dark cloud/circle) for the first time. Even to buy the hackers that will attack. To achieve this standard can become a truly excellent state.
Ultimate Rule Ten
Shirk responsibility (coping with a crash, such as a recent icloud,gmail)
When a service has a security problem and has already produced serious consequences/losses. Find a PR department, issue security bulletins, make statements, and crack down on vulnerable users. And it must be explained that the peers are now almost all this way, not good will only be worse. It is better to say that the manufacturers all over the world have this problem. It can be said that human wisdom can not solve this problem is also possible. Incidentally, I enclose a very small number, saying that they are affected. We have informed them to change the password. As for the loss of compensation, the operation of the game company can be considered. Other enterprises do not recommend giving, otherwise there is a risk of admitting the handle.
When this state is reached, it is almost possible to say "everything is under Control". Perfect state.
[Turn] How to be qualified "Remember password" implementation