Math.Random()

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • JosAH
    Recognized Expert MVP
    • Mar 2007
    • 11453

    #16
    Originally posted by blazedaces
    Yes, but what if we treat the customer number sort of like the number on an install disc? If the computer asks for your customer ID and you input 1, you'll be fine no matter what... (I realize there could be other questions to cross-examine and make sure, but still).

    I mean, even then cd key generators are written to get around this, but you have to admit it's a bit more secure...

    Cheaper isn't necessarily better. Still, I have no idea what the goal of this program is so I'm just throwing things in the air here...

    -blazed
    It doesn't work like that: never trust anything by ID (or PK in database speak)
    only. It doesn't matter how the key was created, either sequentially or at random.

    The other data that is associated with the ID/PK (if any) must match too. Maybe
    even a fysical card supplied by the shop. IDs are not for security, they just
    *identify* someone/something. Simpler is better.

    kind regards,

    Jos

    Comment

    • blazedaces
      Contributor
      • May 2007
      • 284

      #17
      Originally posted by JosAH
      It doesn't work like that: never trust anything by ID (or PK in database speak)
      only. It doesn't matter how the key was created, either sequentially or at random.

      The other data that is associated with the ID/PK (if any) must match too. Maybe
      even a fysical card supplied by the shop. IDs are not for security, they just
      *identify* someone/something. Simpler is better.

      kind regards,

      Jos
      Good to know. I will keep this in mind if ever I consider security measures for database security...

      Thanks,

      -blazed

      Comment

      • Tripmaker
        New Member
        • Jun 2007
        • 60

        #18
        Originally posted by RedSon
        I'm still worried about your design decision to use random numbers as unique customer numbers. I think its a poor decision and will likely cause errors a long time in the future probably long after you have moved on. If you don't want to use sequential numbering why not use the current system time to create a customer ID. Then in your documentation you can state that customer IDs are created by looking at the system time so be sure that your computer's time is always correct.

        Thanks. Never thought of that option.

        Petra

        Comment

        • Tripmaker
          New Member
          • Jun 2007
          • 60

          #19
          Originally posted by blazedaces
          Yes, but what if we treat the customer number sort of like the number on an install disc? If the computer asks for your customer ID and you input 1, you'll be fine no matter what... (I realize there could be other questions to cross-examine and make sure, but still).

          I mean, even then cd key generators are written to get around this, but you have to admit it's a bit more secure...

          Cheaper isn't necessarily better. Still, I have no idea what the goal of this program is so I'm just throwing things in the air here...

          -blazed
          To answer your question about the goal. It's only a small project for our lecturer to see if we could design Customer, Employee and Resource GUIs for a Videostore. It was my idea to add the math.Random() method for customerID for a way of quick identification. It's still interesting to read other ideas of how to going about this. Who knows when I need to use it in the future.

          Petra

          Comment

          Working...