Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First of all MD5 is considered insecure for many reasons, first of all, rainbow tables for md5 are enormous by now, and probably cover most of the hash space. Second, there are known attacks that allow you to create hash collisions (to disguise other data in the manner which will produce the same md5 output). Third its 128bits, for today its short. </p> <p>Now back to your question, if you are not hosting any security-critical app, you do not store any private data, medical data, or any other "country law controlled" data, you are good with md5. Going into your algorithm, it's not insecure, but it's not super secure either, its your choice. Only thing you should add is freshness, that is some sort of timestamp telling you the validity period of your message. Secondly, your algorithm does not offer a replay protection :), if user will use this link once and leave it in browser, attacker may use this link again to reset this password. It's pretty serious flaw. So you might want to fix it.</p> <p>But I want to tell you some other thing. DO NOT USE CRYPTO IF IT IS NOT ABSOLUTELY NECESSARY! My humble request. Your password resetting scheme can be easily implemented without crypto and with replay protection, and far more security. All you need to do is add an additional columns to your table "pw_reset_hash" and "reset_validity", and populate them with RANDOM number, and valid date. Issue a user a random number, and clear the fields after it's used, check for validity beforehand. And voila :) Since it's random its probably more secure than any hashing algorithm. But use a secure PRNG.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs MD5 still considered secure for single use authentications?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USdamiankolasa
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI see what you are saying, but maybe there is another idea. What if I ignore crypto, and take the random number thing a bit farther, and just generate a UUID (version 4)? I could put that value in the database, along with all the other relevant data, and have the verification link simply reference the UUID. Collisions are extremely unlikely (and I can check for that before insertion) and finding a valid UUID with brute force is also extremely unlikely. Once I am done processing a request, I remove it from the database so it can only be triggered once. Better? http://tinyurl.com/avgsdrx
      singulars
      1. PO
      1. USDivideByHero
    2. COIt's nice :) if you use a secure PRNG to populate the UUID, with enough entropy, and if you are not concerned with validity period of such UUID then you're secure, and crypto free :).
      singulars
      1. PO
      1. USdamiankolasa
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload