Does using GUIDs for IDs make IDs unpredictable?

Question

Say I have a website that stores credit card information and on that site I have a page where users can edit/delete their credit card information.

For the sake of the example lets say the HTML looks like this:

<div>
   xxxx-xxxx-xxxx-1234
   <span data-ccid="6E3E8D62-9F94-4FEE-BD1D-FDF87E1A3C50">Delete</span>
</div>

and that clicking on the Delete text would make a call to delete the credit card with the id in data-ccid.

Is it safe to assume that it would be impossible for someone to predict another credit card ID in the system and fire off a call to delete a card other than their own?

Answer 1

Let's go with the assumption you are using tokenization/encryption techniques sufficient to meet PCI DSS.

No we are looking at an abstract problem of can someone predict a value. The risk factor is that if the value can be guessed or follows a known pattern, one could then delete at will.

The issue of the GUID is irrelevant, because the attack vector is still a brute force attack. While knowing the pattern or algorithms used to create your unique id can certainly help reduce the possibilities to more of a dictionary-bounded attack, the knowledge of the ids ahead of time is not necessary to delete records indiscriminately.

You address the problem by implementing additional controls. First, if this is in a database, you have sufficient logging and transactions in place.

On the way to perform the deletion, there should be additional controls in place. Let's start for the user side: If the record is associated with the user, only the user should have the ability to delete his/her own records. If the user is not authenticated or does not own the records, do not allow the deletion procedure to continue forward. Does the user need to provide a special authorization? Is another variable set in the database or in a the session to allow the deletion (e.g., they need to authorize before the action goes throught?) If there is a sufficient risk, you can implement an out of band confirmation, such as sending a SMS message or maybe a confirmation via email is acceptable. In this scenario, its probably low risk if a user knowingly deletes their own credit card records because they can enter it in again later.

If you have strong authentication, authorization, and transaction controls it will limit the ability to indiscriminately delete values, even if they are known.

As an additional precaution, you may wish to implement heuristics and attack detection algorithms. For example, limit the number of deletions from the same IP address per day. Roll back transactions if there are too many deletions in a given day considering normal deletion patterns, etc.

It sounds from your description a simple POST command is being performed, I would ensure this only happens if there is TLS/SSL, the user is authenticated, there is a CSRF token in the request, etc. I would ensure that all deletes are logged and can be rolled back. Since the deletion would not result in exposure, you can also rely on a post-action notification to the users, "We Confirm you have deleted your credit card on file. If you did not do this, please contact us immediately" etc.

Answer 2

A GUID is a sequence of 128 bits, which follows a specific format and generation rules which aim at ensuring uniqueness. This is not the same thing as unpredictability. Among the 5 standard generation methods (called "versions"), only version 4 may claim to be unpredictable, and only insofar as it uses a cryptographically secure PRNG; under these conditions, you get 122 random bits, which is enough for most purposes requiring unpredictability.

So the exact method you use to produce your GUID matters a lot.

Answer 3

It sounds like the risk you're talking about is what's commonly known as cross-site request forgery ("CSRF"). There are common and well-tested mechanisms for addressing this class of vulnerability, and often even pre-made libraries you can simply include into your code (and many frameworks have CSRF protection built-in!).

Once you have CSRF protection added to your application, it doesn't matter what ID you have associated with the record; you could just number them sequentially like the rest of us do.

Also, bear in mind that while you've noticed the potential vulnerability on this particular page, there are probably dozens of other locations in your code where the same caveats apply. Best to treat them all in one go with a single shared solution than to try to clean each individual form independently.

And to answer your original question: no. GUIDs are just a format for presumably-unique identifiers. Where that ID comes from is up to the implementation. There are several different commonly-used mechanisms for generating new GUIDs, some of them are predictable and some of them less so. But they are typically not cryptographically-sound random numbers.

Answer 4

No, please dont do this!! If your randomization is based on a predictable factor such as time (i.e. pseudo-random), or there is any other kinda bug/information leakage that allows it can be figured out. Instead ensure that the authorized user is authenticated before allowing such queries to be executed.

Or better yet, don't store credit cards yourself, rely on a third party such as paypal to do such financial processing on your behalf.