I don't really see how making a separate table for just the authentication process is going to help much. Nobody's going to bother trying to brute-force an MD5 key

Well, as I mention first off, his basic solution is Good Enough. What I'm saying is in part about security, true, and I'll touch more on that point in a moment. But I also find the idea of attaching an extra column, even a BOOL, for what amounts to a one-off to be a waste of space. In a table that's referenced many times a day, it's just one more thing to manage (unless you choose to leverage it into a level/auth system, and even then...) Once the user is verified, it's useless, and that's not my style, nor one I generally recommend. Call me The Normalizer, if you must. :)

You'll also note that I didn't mention MD5, or any secure hash routine, by name. I must call out one error that I did in editing the original response; the password stored in the Temp table should, indeed, be encrypted -- NO cleartext passwords! But I don't mention a scheme, and that's in part because MD5 is crackable in a non brute-force fashion, as is SHA-1. Now, in my opinion, you're right about MD5 being Good Enough for an authentication URL; it's not a huge deal for this guy's project, nor is SHA-1. But yea, the data that's actually stored in the DB for the password hash itself should be something stronger...and I confess that I didn't want to scare the petitioner half to death. However, I did what to give ideas, and hints on building a solid, flexible foundation for their auth scheme.

One more point, since you touch upon it. Most modern email clients can handle long URLs, no problem. Some, however, cannot, and some people are stuck on them, not to mention the potential of mangling. Because I've seen it happen, I firmly believe that the shorter the URL, the better off the end user is in terms of functionality. And the the less data you pass, esp. over GET, the better off you are in terms of internal security (see any paper on SQL injection for just one set of reasons why).

Either everything should be in one table for the sake of simplicity (and records accessed by ID) or the entire registration record should be in the temp table, and only moved to the primary table once it's been activated.

I like, and would employ, your 2nd solution if I have an application with many "false positives" -- people (or machines) registering, but never verifying. At that point, it becomes cleaner to keep your main user table tidy in that fashion, and I'm glad you brought it up as an option, as well.

----Asim, known to some as Woodrow.

In reply to Re^2: Easy Account Email Verification by Asim
in thread Easy Account Email Verification by debiandude

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.