Rigorously testing a login system?

<p>I&#39;m trying to test a basic (email/password) authentication system, and I&#39;m wondering what the best approach is. Looking through some other projects on github, it seems that they simply hardcode a few simple email/password combinations and leave it at that. </p> <p>Obviously the stringency of testing requirements vary from project to project, but I&#39;m wondering what the best method is for testing these kinds of user facing inputs? Should I just hardcode a few edge cases? Would fuzz-testing be overkill for something like this? What is the approach you folks normally take? </p> <hr/>**评论：**<br/><br/>cjbprime: <pre><p>I&#39;d review what large web frameworks do for testing this, e.g. whatever the most popular Rails account package is. You&#39;ll at least be able to find inspiration for the edge cases.</p></pre>elimist3: <pre><p>Thanks for suggestion. It seems devise pretty much takes much of the same hardcoding approach:</p> <p>devise http auth (email: <a href="mailto:user@test.com" rel="nofollow">user@test.com</a>, password: 12345678) <a href="https://github.com/plataformatec/devise/blob/a2498074f19a047d422222e82257db15eaba9759/test/integration/http_authenticatable_test.rb#L94" rel="nofollow">1</a> <a href="https://github.com/plataformatec/devise/blob/69bee06ceee6280b54304928bb6e55c5064abad8/test/integration/authenticatable_test.rb#L512" rel="nofollow">2</a></p> <p>Good enough them good enough for me I suppose?</p></pre>cjbprime: <pre><p>Eesh, that&#39;s extremely light on testing. It&#39;s easy to think up more criteria:</p> <ul> <li><p>check for passwords that are too long</p></li> <li><p>check that a prefix of a correct password isn&#39;t treated as correct</p></li> <li><p>If you&#39;re doing any strcmp(), check for timing attacks -- <a href="https://codahale.com/a-lesson-in-timing-attacks/" rel="nofollow">https://codahale.com/a-lesson-in-timing-attacks/</a> etc</p></li> </ul></pre>fwcNJ49VR29NUPxFfbK4: <pre><p>Just curious, would sleeping the goroutine for a random amount of milliseconds before returning an authorisation response prevent timing attacks in case there was a timing attack bug somewhere else?</p></pre>cjbprime: <pre><p>No, as I understand it, because people could make multiple requests with the same user/pass and then subtract out the randomness statistically.</p> <p>The only way to handle it properly is to always return in the same amount of time, and to use an algorithm that avoids branching (which can be detectable, even remotely) in its tests.</p></pre>elimist3: <pre><p>Yes, it&#39;s quite surprising that many large projects don&#39;t have exhaustive test suites for authentication. Thanks for the tips!</p></pre>gee55: <pre><p>Don&#39;t forget rate limiting!</p></pre>ToAskMoreQuestions: <pre><p>I don&#39;t do fuzzy testing on this kind of stuff. Just make sure that every code path is tested. You should write out all of the possibilities, and test each one. At the very least, you&#39;ll have.</p> <ul> <li>Valid email, valid password</li> <li>Invalid email</li> <li>Valid email, invalid password</li> <li>Valid email, no password</li> <li>No email</li> </ul> <p>Then, depending on your system, you could have more outcomes. What about lockout after n attempts? Does the lockout have to be reset by an admin, or is it on a timer? Are attempts throttled in any way? (e.g. Users must wait at least n seconds between attempts.)</p></pre>elimist3: <pre><p>Thanks for the suggestions</p></pre>thepciet: <pre><p>In my project I&#39;ve set memory scanning for passwords as the rigorous test idea, to be sure passwords aren&#39;t left in memory and (hopefully) are encrypted.</p></pre>