Is payload integrity encryption important for API?
Do we need to encrypt and sign the payload to prevent tampering and ensure integrity ?
Assuming we have JWT bearer in the header and the API is secured with HTTPS.
Given an example of a payload that will be sent to the API that changes data of a user profile.
"name":"bob","age":10,"gender":"m"
Do we need to do a md5 ( payload + private key ) for a signed payload ?
Example:
md5(namebobage10genderm_private_key)
md5 code = fdd5a4a41fc0ab84d4792fa8b08d8e17
The new payload would be
"name":"bob","age":10,"gender":"m","signed":"fdd5a4a41fc0ab84d4792fa8b08d8e17"
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
Please let me know your thoughts regarding this and do we really need this ? As we already have HTTPS for the API and JWT to authenticate the user calling the api.
EDIT
This is quite subjective , the api call is still vulnerable to man in the middle attack , where the api call can be intercepted via proxy before it hits HTTPS . As long as the attacker does not know the algorithm, whatever data being modified during the intercept will be rejected at the server as a signed payload was sent alongside with the payload to verify at the server end.
Please enlighten me . Thank you
php json api encryption md5
add a comment |
Do we need to encrypt and sign the payload to prevent tampering and ensure integrity ?
Assuming we have JWT bearer in the header and the API is secured with HTTPS.
Given an example of a payload that will be sent to the API that changes data of a user profile.
"name":"bob","age":10,"gender":"m"
Do we need to do a md5 ( payload + private key ) for a signed payload ?
Example:
md5(namebobage10genderm_private_key)
md5 code = fdd5a4a41fc0ab84d4792fa8b08d8e17
The new payload would be
"name":"bob","age":10,"gender":"m","signed":"fdd5a4a41fc0ab84d4792fa8b08d8e17"
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
Please let me know your thoughts regarding this and do we really need this ? As we already have HTTPS for the API and JWT to authenticate the user calling the api.
EDIT
This is quite subjective , the api call is still vulnerable to man in the middle attack , where the api call can be intercepted via proxy before it hits HTTPS . As long as the attacker does not know the algorithm, whatever data being modified during the intercept will be rejected at the server as a signed payload was sent alongside with the payload to verify at the server end.
Please enlighten me . Thank you
php json api encryption md5
2
Just use SSL (HTTPS). Why even consider this home-grown scheme?
– James K Polk
Nov 14 '18 at 4:26
Https ensures integrity as well as privacy wikipedia.org/wiki/HTTPS
– Joni
Nov 14 '18 at 4:42
@JamesKPolk Because some things are done via GET and you don't want legitimate users to be able to fiddle around with the parameters they see in an attempt to get info on other users. Multiple levels of security are a GOOD thing. Things like SSL keep out a 3rd party. Things like message/payload signing keep data sane
– ivanivan
Nov 20 '18 at 1:31
add a comment |
Do we need to encrypt and sign the payload to prevent tampering and ensure integrity ?
Assuming we have JWT bearer in the header and the API is secured with HTTPS.
Given an example of a payload that will be sent to the API that changes data of a user profile.
"name":"bob","age":10,"gender":"m"
Do we need to do a md5 ( payload + private key ) for a signed payload ?
Example:
md5(namebobage10genderm_private_key)
md5 code = fdd5a4a41fc0ab84d4792fa8b08d8e17
The new payload would be
"name":"bob","age":10,"gender":"m","signed":"fdd5a4a41fc0ab84d4792fa8b08d8e17"
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
Please let me know your thoughts regarding this and do we really need this ? As we already have HTTPS for the API and JWT to authenticate the user calling the api.
EDIT
This is quite subjective , the api call is still vulnerable to man in the middle attack , where the api call can be intercepted via proxy before it hits HTTPS . As long as the attacker does not know the algorithm, whatever data being modified during the intercept will be rejected at the server as a signed payload was sent alongside with the payload to verify at the server end.
Please enlighten me . Thank you
php json api encryption md5
Do we need to encrypt and sign the payload to prevent tampering and ensure integrity ?
Assuming we have JWT bearer in the header and the API is secured with HTTPS.
Given an example of a payload that will be sent to the API that changes data of a user profile.
"name":"bob","age":10,"gender":"m"
Do we need to do a md5 ( payload + private key ) for a signed payload ?
Example:
md5(namebobage10genderm_private_key)
md5 code = fdd5a4a41fc0ab84d4792fa8b08d8e17
The new payload would be
"name":"bob","age":10,"gender":"m","signed":"fdd5a4a41fc0ab84d4792fa8b08d8e17"
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
Please let me know your thoughts regarding this and do we really need this ? As we already have HTTPS for the API and JWT to authenticate the user calling the api.
EDIT
This is quite subjective , the api call is still vulnerable to man in the middle attack , where the api call can be intercepted via proxy before it hits HTTPS . As long as the attacker does not know the algorithm, whatever data being modified during the intercept will be rejected at the server as a signed payload was sent alongside with the payload to verify at the server end.
Please enlighten me . Thank you
php json api encryption md5
php json api encryption md5
edited Nov 15 '18 at 6:49
zerowind
asked Nov 14 '18 at 4:14
zerowindzerowind
94
94
2
Just use SSL (HTTPS). Why even consider this home-grown scheme?
– James K Polk
Nov 14 '18 at 4:26
Https ensures integrity as well as privacy wikipedia.org/wiki/HTTPS
– Joni
Nov 14 '18 at 4:42
@JamesKPolk Because some things are done via GET and you don't want legitimate users to be able to fiddle around with the parameters they see in an attempt to get info on other users. Multiple levels of security are a GOOD thing. Things like SSL keep out a 3rd party. Things like message/payload signing keep data sane
– ivanivan
Nov 20 '18 at 1:31
add a comment |
2
Just use SSL (HTTPS). Why even consider this home-grown scheme?
– James K Polk
Nov 14 '18 at 4:26
Https ensures integrity as well as privacy wikipedia.org/wiki/HTTPS
– Joni
Nov 14 '18 at 4:42
@JamesKPolk Because some things are done via GET and you don't want legitimate users to be able to fiddle around with the parameters they see in an attempt to get info on other users. Multiple levels of security are a GOOD thing. Things like SSL keep out a 3rd party. Things like message/payload signing keep data sane
– ivanivan
Nov 20 '18 at 1:31
2
2
Just use SSL (HTTPS). Why even consider this home-grown scheme?
– James K Polk
Nov 14 '18 at 4:26
Just use SSL (HTTPS). Why even consider this home-grown scheme?
– James K Polk
Nov 14 '18 at 4:26
Https ensures integrity as well as privacy wikipedia.org/wiki/HTTPS
– Joni
Nov 14 '18 at 4:42
Https ensures integrity as well as privacy wikipedia.org/wiki/HTTPS
– Joni
Nov 14 '18 at 4:42
@JamesKPolk Because some things are done via GET and you don't want legitimate users to be able to fiddle around with the parameters they see in an attempt to get info on other users. Multiple levels of security are a GOOD thing. Things like SSL keep out a 3rd party. Things like message/payload signing keep data sane
– ivanivan
Nov 20 '18 at 1:31
@JamesKPolk Because some things are done via GET and you don't want legitimate users to be able to fiddle around with the parameters they see in an attempt to get info on other users. Multiple levels of security are a GOOD thing. Things like SSL keep out a 3rd party. Things like message/payload signing keep data sane
– ivanivan
Nov 20 '18 at 1:31
add a comment |
1 Answer
1
active
oldest
votes
Is payload integrity encryption important for API?
Integrity and confidentiality are two separate properties.
Encryption provides confidentiality. Some encryption modes also provide authentication. We call these authenticated encryption, IND-CCA3, and/or AEAD, depending on some details.
You want authenticated encryption.
Do we need to do a md5 ( payload + private key ) for a signed payload ? Example:
Don't use MD5 for anything. It's been broken for many years now.
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
MD5 isn't an encryption function. It's a hash function.
The easiest answer to this situation that won't leave your app totally insecure is: Use PASETO instead of JWT and then you don't need to anguish over whether or not you need to encrypt, sign, or both.
v1.local
and v2.local
provide authenticated encryption. Use one of the two (v2 is better, v1 is for compatibility). You don't need to do anything on top of PASETO to make it secure, it already provides integrity guarantees.
Further reading: PASETO is a Secure Alternative to the JOSE Standards (JWT, etc.) (Disclaimer: I'm the author.)
PASETO doesn't obviate the need for HTTPS, but you've already expressed that you're using HTTPS, so, just keep doing that.
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%2f53293105%2fis-payload-integrity-encryption-important-for-api%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
Is payload integrity encryption important for API?
Integrity and confidentiality are two separate properties.
Encryption provides confidentiality. Some encryption modes also provide authentication. We call these authenticated encryption, IND-CCA3, and/or AEAD, depending on some details.
You want authenticated encryption.
Do we need to do a md5 ( payload + private key ) for a signed payload ? Example:
Don't use MD5 for anything. It's been broken for many years now.
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
MD5 isn't an encryption function. It's a hash function.
The easiest answer to this situation that won't leave your app totally insecure is: Use PASETO instead of JWT and then you don't need to anguish over whether or not you need to encrypt, sign, or both.
v1.local
and v2.local
provide authenticated encryption. Use one of the two (v2 is better, v1 is for compatibility). You don't need to do anything on top of PASETO to make it secure, it already provides integrity guarantees.
Further reading: PASETO is a Secure Alternative to the JOSE Standards (JWT, etc.) (Disclaimer: I'm the author.)
PASETO doesn't obviate the need for HTTPS, but you've already expressed that you're using HTTPS, so, just keep doing that.
add a comment |
Is payload integrity encryption important for API?
Integrity and confidentiality are two separate properties.
Encryption provides confidentiality. Some encryption modes also provide authentication. We call these authenticated encryption, IND-CCA3, and/or AEAD, depending on some details.
You want authenticated encryption.
Do we need to do a md5 ( payload + private key ) for a signed payload ? Example:
Don't use MD5 for anything. It's been broken for many years now.
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
MD5 isn't an encryption function. It's a hash function.
The easiest answer to this situation that won't leave your app totally insecure is: Use PASETO instead of JWT and then you don't need to anguish over whether or not you need to encrypt, sign, or both.
v1.local
and v2.local
provide authenticated encryption. Use one of the two (v2 is better, v1 is for compatibility). You don't need to do anything on top of PASETO to make it secure, it already provides integrity guarantees.
Further reading: PASETO is a Secure Alternative to the JOSE Standards (JWT, etc.) (Disclaimer: I'm the author.)
PASETO doesn't obviate the need for HTTPS, but you've already expressed that you're using HTTPS, so, just keep doing that.
add a comment |
Is payload integrity encryption important for API?
Integrity and confidentiality are two separate properties.
Encryption provides confidentiality. Some encryption modes also provide authentication. We call these authenticated encryption, IND-CCA3, and/or AEAD, depending on some details.
You want authenticated encryption.
Do we need to do a md5 ( payload + private key ) for a signed payload ? Example:
Don't use MD5 for anything. It's been broken for many years now.
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
MD5 isn't an encryption function. It's a hash function.
The easiest answer to this situation that won't leave your app totally insecure is: Use PASETO instead of JWT and then you don't need to anguish over whether or not you need to encrypt, sign, or both.
v1.local
and v2.local
provide authenticated encryption. Use one of the two (v2 is better, v1 is for compatibility). You don't need to do anything on top of PASETO to make it secure, it already provides integrity guarantees.
Further reading: PASETO is a Secure Alternative to the JOSE Standards (JWT, etc.) (Disclaimer: I'm the author.)
PASETO doesn't obviate the need for HTTPS, but you've already expressed that you're using HTTPS, so, just keep doing that.
Is payload integrity encryption important for API?
Integrity and confidentiality are two separate properties.
Encryption provides confidentiality. Some encryption modes also provide authentication. We call these authenticated encryption, IND-CCA3, and/or AEAD, depending on some details.
You want authenticated encryption.
Do we need to do a md5 ( payload + private key ) for a signed payload ? Example:
Don't use MD5 for anything. It's been broken for many years now.
When the server receives the API call , it will also do the md5 encryption of the payload and compares the signed value in order to ensure integrity.
MD5 isn't an encryption function. It's a hash function.
The easiest answer to this situation that won't leave your app totally insecure is: Use PASETO instead of JWT and then you don't need to anguish over whether or not you need to encrypt, sign, or both.
v1.local
and v2.local
provide authenticated encryption. Use one of the two (v2 is better, v1 is for compatibility). You don't need to do anything on top of PASETO to make it secure, it already provides integrity guarantees.
Further reading: PASETO is a Secure Alternative to the JOSE Standards (JWT, etc.) (Disclaimer: I'm the author.)
PASETO doesn't obviate the need for HTTPS, but you've already expressed that you're using HTTPS, so, just keep doing that.
answered Nov 20 '18 at 1:01
Scott ArciszewskiScott Arciszewski
22.9k957155
22.9k957155
add a comment |
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%2f53293105%2fis-payload-integrity-encryption-important-for-api%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
2
Just use SSL (HTTPS). Why even consider this home-grown scheme?
– James K Polk
Nov 14 '18 at 4:26
Https ensures integrity as well as privacy wikipedia.org/wiki/HTTPS
– Joni
Nov 14 '18 at 4:42
@JamesKPolk Because some things are done via GET and you don't want legitimate users to be able to fiddle around with the parameters they see in an attempt to get info on other users. Multiple levels of security are a GOOD thing. Things like SSL keep out a 3rd party. Things like message/payload signing keep data sane
– ivanivan
Nov 20 '18 at 1:31