Is UUID v3 insecure for generating surrogate keys for APIs since it is based on MD5?
Background:
I want to generate surrogate/alternate keys in my database so that I can expose them publicly as my resource identifiers in my API endpoints as follows: GET /resources/{id}
The data in question is a copy of the source-of-truth database and the only identifiers in my copy are sensitive and cannot be exposed in the URL.
So I want to generate a new but reproducible identifier from the existing data and I am considering using UUID v3. (or v5 but I don't see any Java official implementations) Reproducible in the event that my copy has to be recreated, then I can be sure I reproduce the same identifier.
In the event it matters the data is stored in a SQL Server database.
Question: Is UUID v3/5 safe to use in this way since they are based on MD5/SHA-1?
java sql-server rest md5 uuid
add a comment |
Background:
I want to generate surrogate/alternate keys in my database so that I can expose them publicly as my resource identifiers in my API endpoints as follows: GET /resources/{id}
The data in question is a copy of the source-of-truth database and the only identifiers in my copy are sensitive and cannot be exposed in the URL.
So I want to generate a new but reproducible identifier from the existing data and I am considering using UUID v3. (or v5 but I don't see any Java official implementations) Reproducible in the event that my copy has to be recreated, then I can be sure I reproduce the same identifier.
In the event it matters the data is stored in a SQL Server database.
Question: Is UUID v3/5 safe to use in this way since they are based on MD5/SHA-1?
java sql-server rest md5 uuid
This answer might help: stackoverflow.com/questions/5728205/…
– moilejter
Nov 26 '18 at 3:29
1
@GhostCat Thanks. Corrected.
– gb.
Nov 26 '18 at 3:54
add a comment |
Background:
I want to generate surrogate/alternate keys in my database so that I can expose them publicly as my resource identifiers in my API endpoints as follows: GET /resources/{id}
The data in question is a copy of the source-of-truth database and the only identifiers in my copy are sensitive and cannot be exposed in the URL.
So I want to generate a new but reproducible identifier from the existing data and I am considering using UUID v3. (or v5 but I don't see any Java official implementations) Reproducible in the event that my copy has to be recreated, then I can be sure I reproduce the same identifier.
In the event it matters the data is stored in a SQL Server database.
Question: Is UUID v3/5 safe to use in this way since they are based on MD5/SHA-1?
java sql-server rest md5 uuid
Background:
I want to generate surrogate/alternate keys in my database so that I can expose them publicly as my resource identifiers in my API endpoints as follows: GET /resources/{id}
The data in question is a copy of the source-of-truth database and the only identifiers in my copy are sensitive and cannot be exposed in the URL.
So I want to generate a new but reproducible identifier from the existing data and I am considering using UUID v3. (or v5 but I don't see any Java official implementations) Reproducible in the event that my copy has to be recreated, then I can be sure I reproduce the same identifier.
In the event it matters the data is stored in a SQL Server database.
Question: Is UUID v3/5 safe to use in this way since they are based on MD5/SHA-1?
java sql-server rest md5 uuid
java sql-server rest md5 uuid
edited Nov 26 '18 at 3:53
gb.
asked Nov 26 '18 at 3:26
gb.gb.
6217
6217
This answer might help: stackoverflow.com/questions/5728205/…
– moilejter
Nov 26 '18 at 3:29
1
@GhostCat Thanks. Corrected.
– gb.
Nov 26 '18 at 3:54
add a comment |
This answer might help: stackoverflow.com/questions/5728205/…
– moilejter
Nov 26 '18 at 3:29
1
@GhostCat Thanks. Corrected.
– gb.
Nov 26 '18 at 3:54
This answer might help: stackoverflow.com/questions/5728205/…
– moilejter
Nov 26 '18 at 3:29
This answer might help: stackoverflow.com/questions/5728205/…
– moilejter
Nov 26 '18 at 3:29
1
1
@GhostCat Thanks. Corrected.
– gb.
Nov 26 '18 at 3:54
@GhostCat Thanks. Corrected.
– gb.
Nov 26 '18 at 3:54
add a comment |
1 Answer
1
active
oldest
votes
Version 3 is deprecated for a reason. There's no known way (other than brute force) to get from the UUID back to the name, but MD5 does have problems and attacks only get better over time. If the library you're using doesn't support version 5 yet, get one that does.
For both of them, if the amount of data going into the hash is small, then brute force may be a real concern for both versions. The answer to that is to use more input data, i.e. enough that brute force is no longer possible. The exact options will depend on what you have available and how guessable it is
I can't find where version 3 is deprecated. Could you provide a source?
– gb.
Nov 28 '18 at 1:04
Accepted as the answer due to "MD5 does have problems and attacks only get better over time." Even if the current attack vectors regarding collisions may not impact me now, it may in the future or another issue may arise. So best not to use it. Technically, I consider this the same for SHA-1.
– gb.
Nov 28 '18 at 16:22
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53474420%2fis-uuid-v3-insecure-for-generating-surrogate-keys-for-apis-since-it-is-based-on%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Version 3 is deprecated for a reason. There's no known way (other than brute force) to get from the UUID back to the name, but MD5 does have problems and attacks only get better over time. If the library you're using doesn't support version 5 yet, get one that does.
For both of them, if the amount of data going into the hash is small, then brute force may be a real concern for both versions. The answer to that is to use more input data, i.e. enough that brute force is no longer possible. The exact options will depend on what you have available and how guessable it is
I can't find where version 3 is deprecated. Could you provide a source?
– gb.
Nov 28 '18 at 1:04
Accepted as the answer due to "MD5 does have problems and attacks only get better over time." Even if the current attack vectors regarding collisions may not impact me now, it may in the future or another issue may arise. So best not to use it. Technically, I consider this the same for SHA-1.
– gb.
Nov 28 '18 at 16:22
add a comment |
Version 3 is deprecated for a reason. There's no known way (other than brute force) to get from the UUID back to the name, but MD5 does have problems and attacks only get better over time. If the library you're using doesn't support version 5 yet, get one that does.
For both of them, if the amount of data going into the hash is small, then brute force may be a real concern for both versions. The answer to that is to use more input data, i.e. enough that brute force is no longer possible. The exact options will depend on what you have available and how guessable it is
I can't find where version 3 is deprecated. Could you provide a source?
– gb.
Nov 28 '18 at 1:04
Accepted as the answer due to "MD5 does have problems and attacks only get better over time." Even if the current attack vectors regarding collisions may not impact me now, it may in the future or another issue may arise. So best not to use it. Technically, I consider this the same for SHA-1.
– gb.
Nov 28 '18 at 16:22
add a comment |
Version 3 is deprecated for a reason. There's no known way (other than brute force) to get from the UUID back to the name, but MD5 does have problems and attacks only get better over time. If the library you're using doesn't support version 5 yet, get one that does.
For both of them, if the amount of data going into the hash is small, then brute force may be a real concern for both versions. The answer to that is to use more input data, i.e. enough that brute force is no longer possible. The exact options will depend on what you have available and how guessable it is
Version 3 is deprecated for a reason. There's no known way (other than brute force) to get from the UUID back to the name, but MD5 does have problems and attacks only get better over time. If the library you're using doesn't support version 5 yet, get one that does.
For both of them, if the amount of data going into the hash is small, then brute force may be a real concern for both versions. The answer to that is to use more input data, i.e. enough that brute force is no longer possible. The exact options will depend on what you have available and how guessable it is
answered Nov 27 '18 at 16:40
StephenSStephenS
30524
30524
I can't find where version 3 is deprecated. Could you provide a source?
– gb.
Nov 28 '18 at 1:04
Accepted as the answer due to "MD5 does have problems and attacks only get better over time." Even if the current attack vectors regarding collisions may not impact me now, it may in the future or another issue may arise. So best not to use it. Technically, I consider this the same for SHA-1.
– gb.
Nov 28 '18 at 16:22
add a comment |
I can't find where version 3 is deprecated. Could you provide a source?
– gb.
Nov 28 '18 at 1:04
Accepted as the answer due to "MD5 does have problems and attacks only get better over time." Even if the current attack vectors regarding collisions may not impact me now, it may in the future or another issue may arise. So best not to use it. Technically, I consider this the same for SHA-1.
– gb.
Nov 28 '18 at 16:22
I can't find where version 3 is deprecated. Could you provide a source?
– gb.
Nov 28 '18 at 1:04
I can't find where version 3 is deprecated. Could you provide a source?
– gb.
Nov 28 '18 at 1:04
Accepted as the answer due to "MD5 does have problems and attacks only get better over time." Even if the current attack vectors regarding collisions may not impact me now, it may in the future or another issue may arise. So best not to use it. Technically, I consider this the same for SHA-1.
– gb.
Nov 28 '18 at 16:22
Accepted as the answer due to "MD5 does have problems and attacks only get better over time." Even if the current attack vectors regarding collisions may not impact me now, it may in the future or another issue may arise. So best not to use it. Technically, I consider this the same for SHA-1.
– gb.
Nov 28 '18 at 16:22
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53474420%2fis-uuid-v3-insecure-for-generating-surrogate-keys-for-apis-since-it-is-based-on%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This answer might help: stackoverflow.com/questions/5728205/…
– moilejter
Nov 26 '18 at 3:29
1
@GhostCat Thanks. Corrected.
– gb.
Nov 26 '18 at 3:54