How to avoid using System.String with Rfc2898DeriveBytes in C#Is this security/encryption scheme...
Solve a logarithmic equation by NSolve
What is the evidence on the danger of feeding whole blueberries and grapes to infants and toddlers?
Why does The Ancient One think differently about Doctor Strange in Endgame than the film Doctor Strange?
What professions would a medieval village with a population of 100 need?
What can I do to keep a threaded bolt from falling out of its slot?
Does an object count as "being moved" when placed in a Bag of Holding before its wielder moves, and then after moving they take the object out again?
Have only girls been born for a long time in this village?
Is there such a thing as too inconvenient?
System to validate run time complexity requirements
Were there 486SX revisions without an FPU on the die?
In an emergency, how do I find and share my position?
If the first law of thermodynamics ensures conservation of energy, why does it allow systems to lose energy?
On the feasibility of space battleships
Why did MS-DOS applications built using Turbo Pascal fail to start with a division by zero error on faster systems?
Was Switzerland really impossible to invade during WW2?
How would one country purchase another?
How to refer to a regex group in awk regex?
How to dismiss intrusive questions from a colleague with whom I don't work?
Can a character spend multiple hit dice at level 1?
Are required indicators necessary for radio buttons?
confused about grep and the * wildcard
Do ability scores have any effect on casting Wish spell
Concatenation of the result of a function with a mutable default argument in python
How big would a Daddy Longlegs Spider need to be to kill an average Human?
How to avoid using System.String with Rfc2898DeriveBytes in C#
Is this security/encryption scheme secure?HMACSHA512 versus Rfc2898DeriveBytes for password hashSecurity concerns with a “fiddle” site?How to avoid web service spam?Is Rfc2898DeriveBytes using HMAC SHA1 still considered “secure enough” for hashing passwords?Passing encryption with IV as a single arrayAvoid being hacked with brute-force attack
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I am creating a .NET core webapp in C# that takes in a user password and hashes it to be stored on a server. I'm using Rfc2898DeriveBytes along with a randomly generated salt. I've read, however, that I should avoid using strings in the entire process since strings cannot be removed from memory. I know that .NET core has a PasswordBox that keeps the password as a SecureString, but SecureStrings cannot be converted to a byte array to be passed to Rfc2898DeriveBytes's constructor without a great deal of shenanigans.
Since the webapp is only going to run on my server, can I just convert the SecureString back to a string as soon as it has been passed into my webapp? If an attacker manages to access the server's RAM to search for an undeleted string, there's probably very little I can do to protect anything to begin with.
If I should still go through with using SecureStrings, what are the best practices for hashing it to be stored?
passwords web-application .net asp.net-core
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I am creating a .NET core webapp in C# that takes in a user password and hashes it to be stored on a server. I'm using Rfc2898DeriveBytes along with a randomly generated salt. I've read, however, that I should avoid using strings in the entire process since strings cannot be removed from memory. I know that .NET core has a PasswordBox that keeps the password as a SecureString, but SecureStrings cannot be converted to a byte array to be passed to Rfc2898DeriveBytes's constructor without a great deal of shenanigans.
Since the webapp is only going to run on my server, can I just convert the SecureString back to a string as soon as it has been passed into my webapp? If an attacker manages to access the server's RAM to search for an undeleted string, there's probably very little I can do to protect anything to begin with.
If I should still go through with using SecureStrings, what are the best practices for hashing it to be stored?
passwords web-application .net asp.net-core
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I am creating a .NET core webapp in C# that takes in a user password and hashes it to be stored on a server. I'm using Rfc2898DeriveBytes along with a randomly generated salt. I've read, however, that I should avoid using strings in the entire process since strings cannot be removed from memory. I know that .NET core has a PasswordBox that keeps the password as a SecureString, but SecureStrings cannot be converted to a byte array to be passed to Rfc2898DeriveBytes's constructor without a great deal of shenanigans.
Since the webapp is only going to run on my server, can I just convert the SecureString back to a string as soon as it has been passed into my webapp? If an attacker manages to access the server's RAM to search for an undeleted string, there's probably very little I can do to protect anything to begin with.
If I should still go through with using SecureStrings, what are the best practices for hashing it to be stored?
passwords web-application .net asp.net-core
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I am creating a .NET core webapp in C# that takes in a user password and hashes it to be stored on a server. I'm using Rfc2898DeriveBytes along with a randomly generated salt. I've read, however, that I should avoid using strings in the entire process since strings cannot be removed from memory. I know that .NET core has a PasswordBox that keeps the password as a SecureString, but SecureStrings cannot be converted to a byte array to be passed to Rfc2898DeriveBytes's constructor without a great deal of shenanigans.
Since the webapp is only going to run on my server, can I just convert the SecureString back to a string as soon as it has been passed into my webapp? If an attacker manages to access the server's RAM to search for an undeleted string, there's probably very little I can do to protect anything to begin with.
If I should still go through with using SecureStrings, what are the best practices for hashing it to be stored?
passwords web-application .net asp.net-core
passwords web-application .net asp.net-core
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
edited 2 days ago
schroeder♦
85.1k34 gold badges190 silver badges228 bronze badges
85.1k34 gold badges190 silver badges228 bronze badges
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
asked 2 days ago
JeffJeff
1282 silver badges5 bronze badges
1282 silver badges5 bronze badges
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Jeff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Using SecureString correctly is difficult, and protects against a threat surface that is unlikely for most use cases. As you say, if an attacker can read your memory, you have other problems. I would advise to use normal strings instead of SecureString, unless you are worried by attackers carrying liquid nitrogen with physical access to your server.
If you really want to use SecureStrings, you should P/Invoke the Windows crypto API so that you have control over memory. I have an example in my blog post Comparing secure strings in .NET.
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
7
No liquid nitrogen needed: there software (Heartbleed) vulnerabilities that allow reading parts of RAM, and hardware vulnerabilities like Spectre can be exploited in a cloud environment. But I agree that it's rather unlikely and not something most web apps should be concerned with.
– aland
yesterday
add a comment |
The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation:
We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.
as well as the team's reasoning on GitHub:
Motivation
- The purpose of
SecureStringis to avoid having secrets stored in the process
memory as plain text.
- However, even on Windows,
SecureStringdoesn't exist as an OS concept.
- It just makes the window getting the plain text shorter; it doesn't fully
prevent it as .NET still has to convert the string to a plain text
representation.
- The benefit is that the plain text representation doesn't hang around
as an instance ofSystem.String-- the lifetime of the native buffer is
shorter.
- The contents of the array is unencrypted except on .NET Framework.
- In .NET Framework, the contents of the internal char array is encrypted.
.NET doesn't support encryption in all environments, either
due to missing APIs or key management issues.
edited yesterday
eis
1054 bronze badges
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Very interesting, great first answer! It should be noted that process memory in general is only really an attack surface if an attacker is able to get access to it - something that is generally not part of the threat model of a web application, unless on a shared host.
– MechMK1
2 days ago
@MechMK1 That is mentioned in the other answer already, I just wanted to add the official recommendation, too.
– Vivelin
2 days ago
The quoted part says nothing about recommending against using SecureString. Could you please quote (or bold) the relevant parts.
– Andrew Savinykh
2 days ago
2
@AndrewSavinykh It's in the first link and doesn't really say more than that they don't recommend it for new development and contains a link to the quoted part.
– Vivelin
yesterday
@AndrewSavinykh I assume because it's a huge pain to work with, and in the end it has to end up in plaintext anyways, so there is little use to it
– MechMK1
yesterday
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Jeff is a new contributor. Be nice, and check out our Code of Conduct.
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%2fsecurity.stackexchange.com%2fquestions%2f215554%2fhow-to-avoid-using-system-string-with-rfc2898derivebytes-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Using SecureString correctly is difficult, and protects against a threat surface that is unlikely for most use cases. As you say, if an attacker can read your memory, you have other problems. I would advise to use normal strings instead of SecureString, unless you are worried by attackers carrying liquid nitrogen with physical access to your server.
If you really want to use SecureStrings, you should P/Invoke the Windows crypto API so that you have control over memory. I have an example in my blog post Comparing secure strings in .NET.
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
7
No liquid nitrogen needed: there software (Heartbleed) vulnerabilities that allow reading parts of RAM, and hardware vulnerabilities like Spectre can be exploited in a cloud environment. But I agree that it's rather unlikely and not something most web apps should be concerned with.
– aland
yesterday
add a comment |
Using SecureString correctly is difficult, and protects against a threat surface that is unlikely for most use cases. As you say, if an attacker can read your memory, you have other problems. I would advise to use normal strings instead of SecureString, unless you are worried by attackers carrying liquid nitrogen with physical access to your server.
If you really want to use SecureStrings, you should P/Invoke the Windows crypto API so that you have control over memory. I have an example in my blog post Comparing secure strings in .NET.
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
7
No liquid nitrogen needed: there software (Heartbleed) vulnerabilities that allow reading parts of RAM, and hardware vulnerabilities like Spectre can be exploited in a cloud environment. But I agree that it's rather unlikely and not something most web apps should be concerned with.
– aland
yesterday
add a comment |
Using SecureString correctly is difficult, and protects against a threat surface that is unlikely for most use cases. As you say, if an attacker can read your memory, you have other problems. I would advise to use normal strings instead of SecureString, unless you are worried by attackers carrying liquid nitrogen with physical access to your server.
If you really want to use SecureStrings, you should P/Invoke the Windows crypto API so that you have control over memory. I have an example in my blog post Comparing secure strings in .NET.
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
Using SecureString correctly is difficult, and protects against a threat surface that is unlikely for most use cases. As you say, if an attacker can read your memory, you have other problems. I would advise to use normal strings instead of SecureString, unless you are worried by attackers carrying liquid nitrogen with physical access to your server.
If you really want to use SecureStrings, you should P/Invoke the Windows crypto API so that you have control over memory. I have an example in my blog post Comparing secure strings in .NET.
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
answered 2 days ago
SjoerdSjoerd
22.7k9 gold badges54 silver badges72 bronze badges
22.7k9 gold badges54 silver badges72 bronze badges
7
No liquid nitrogen needed: there software (Heartbleed) vulnerabilities that allow reading parts of RAM, and hardware vulnerabilities like Spectre can be exploited in a cloud environment. But I agree that it's rather unlikely and not something most web apps should be concerned with.
– aland
yesterday
add a comment |
7
No liquid nitrogen needed: there software (Heartbleed) vulnerabilities that allow reading parts of RAM, and hardware vulnerabilities like Spectre can be exploited in a cloud environment. But I agree that it's rather unlikely and not something most web apps should be concerned with.
– aland
yesterday
7
7
No liquid nitrogen needed: there software (Heartbleed) vulnerabilities that allow reading parts of RAM, and hardware vulnerabilities like Spectre can be exploited in a cloud environment. But I agree that it's rather unlikely and not something most web apps should be concerned with.
– aland
yesterday
No liquid nitrogen needed: there software (Heartbleed) vulnerabilities that allow reading parts of RAM, and hardware vulnerabilities like Spectre can be exploited in a cloud environment. But I agree that it's rather unlikely and not something most web apps should be concerned with.
– aland
yesterday
add a comment |
The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation:
We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.
as well as the team's reasoning on GitHub:
Motivation
- The purpose of
SecureStringis to avoid having secrets stored in the process
memory as plain text.
- However, even on Windows,
SecureStringdoesn't exist as an OS concept.
- It just makes the window getting the plain text shorter; it doesn't fully
prevent it as .NET still has to convert the string to a plain text
representation.
- The benefit is that the plain text representation doesn't hang around
as an instance ofSystem.String-- the lifetime of the native buffer is
shorter.
- The contents of the array is unencrypted except on .NET Framework.
- In .NET Framework, the contents of the internal char array is encrypted.
.NET doesn't support encryption in all environments, either
due to missing APIs or key management issues.
edited yesterday
eis
1054 bronze badges
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Very interesting, great first answer! It should be noted that process memory in general is only really an attack surface if an attacker is able to get access to it - something that is generally not part of the threat model of a web application, unless on a shared host.
– MechMK1
2 days ago
@MechMK1 That is mentioned in the other answer already, I just wanted to add the official recommendation, too.
– Vivelin
2 days ago
The quoted part says nothing about recommending against using SecureString. Could you please quote (or bold) the relevant parts.
– Andrew Savinykh
2 days ago
2
@AndrewSavinykh It's in the first link and doesn't really say more than that they don't recommend it for new development and contains a link to the quoted part.
– Vivelin
yesterday
@AndrewSavinykh I assume because it's a huge pain to work with, and in the end it has to end up in plaintext anyways, so there is little use to it
– MechMK1
yesterday
|
show 1 more comment
The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation:
We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.
as well as the team's reasoning on GitHub:
Motivation
- The purpose of
SecureStringis to avoid having secrets stored in the process
memory as plain text.
- However, even on Windows,
SecureStringdoesn't exist as an OS concept.
- It just makes the window getting the plain text shorter; it doesn't fully
prevent it as .NET still has to convert the string to a plain text
representation.
- The benefit is that the plain text representation doesn't hang around
as an instance ofSystem.String-- the lifetime of the native buffer is
shorter.
- The contents of the array is unencrypted except on .NET Framework.
- In .NET Framework, the contents of the internal char array is encrypted.
.NET doesn't support encryption in all environments, either
due to missing APIs or key management issues.
edited yesterday
eis
1054 bronze badges
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Very interesting, great first answer! It should be noted that process memory in general is only really an attack surface if an attacker is able to get access to it - something that is generally not part of the threat model of a web application, unless on a shared host.
– MechMK1
2 days ago
@MechMK1 That is mentioned in the other answer already, I just wanted to add the official recommendation, too.
– Vivelin
2 days ago
The quoted part says nothing about recommending against using SecureString. Could you please quote (or bold) the relevant parts.
– Andrew Savinykh
2 days ago
2
@AndrewSavinykh It's in the first link and doesn't really say more than that they don't recommend it for new development and contains a link to the quoted part.
– Vivelin
yesterday
@AndrewSavinykh I assume because it's a huge pain to work with, and in the end it has to end up in plaintext anyways, so there is little use to it
– MechMK1
yesterday
|
show 1 more comment
The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation:
We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.
as well as the team's reasoning on GitHub:
Motivation
- The purpose of
SecureStringis to avoid having secrets stored in the process
memory as plain text.
- However, even on Windows,
SecureStringdoesn't exist as an OS concept.
- It just makes the window getting the plain text shorter; it doesn't fully
prevent it as .NET still has to convert the string to a plain text
representation.
- The benefit is that the plain text representation doesn't hang around
as an instance ofSystem.String-- the lifetime of the native buffer is
shorter.
- The contents of the array is unencrypted except on .NET Framework.
- In .NET Framework, the contents of the internal char array is encrypted.
.NET doesn't support encryption in all environments, either
due to missing APIs or key management issues.
edited yesterday
eis
1054 bronze badges
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation:
We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.
as well as the team's reasoning on GitHub:
Motivation
- The purpose of
SecureStringis to avoid having secrets stored in the process
memory as plain text.
- However, even on Windows,
SecureStringdoesn't exist as an OS concept.
- It just makes the window getting the plain text shorter; it doesn't fully
prevent it as .NET still has to convert the string to a plain text
representation.
- The benefit is that the plain text representation doesn't hang around
as an instance ofSystem.String-- the lifetime of the native buffer is
shorter.
- The contents of the array is unencrypted except on .NET Framework.
- In .NET Framework, the contents of the internal char array is encrypted.
.NET doesn't support encryption in all environments, either
due to missing APIs or key management issues.
edited yesterday
eis
1054 bronze badges
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
eis
1054 bronze badges
edited yesterday
eis
1054 bronze badges
edited yesterday
eis
1054 bronze badges
1054 bronze badges
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
answered 2 days ago
VivelinVivelin
5013 silver badges7 bronze badges
5013 silver badges7 bronze badges
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Vivelin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Very interesting, great first answer! It should be noted that process memory in general is only really an attack surface if an attacker is able to get access to it - something that is generally not part of the threat model of a web application, unless on a shared host.
– MechMK1
2 days ago
@MechMK1 That is mentioned in the other answer already, I just wanted to add the official recommendation, too.
– Vivelin
2 days ago
The quoted part says nothing about recommending against using SecureString. Could you please quote (or bold) the relevant parts.
– Andrew Savinykh
2 days ago
2
@AndrewSavinykh It's in the first link and doesn't really say more than that they don't recommend it for new development and contains a link to the quoted part.
– Vivelin
yesterday
@AndrewSavinykh I assume because it's a huge pain to work with, and in the end it has to end up in plaintext anyways, so there is little use to it
– MechMK1
yesterday
|
show 1 more comment
2
Very interesting, great first answer! It should be noted that process memory in general is only really an attack surface if an attacker is able to get access to it - something that is generally not part of the threat model of a web application, unless on a shared host.
– MechMK1
2 days ago
@MechMK1 That is mentioned in the other answer already, I just wanted to add the official recommendation, too.
– Vivelin
2 days ago
The quoted part says nothing about recommending against using SecureString. Could you please quote (or bold) the relevant parts.
– Andrew Savinykh
2 days ago
2
@AndrewSavinykh It's in the first link and doesn't really say more than that they don't recommend it for new development and contains a link to the quoted part.
– Vivelin
yesterday
@AndrewSavinykh I assume because it's a huge pain to work with, and in the end it has to end up in plaintext anyways, so there is little use to it
– MechMK1
yesterday
2
2
Very interesting, great first answer! It should be noted that process memory in general is only really an attack surface if an attacker is able to get access to it - something that is generally not part of the threat model of a web application, unless on a shared host.
– MechMK1
2 days ago
Very interesting, great first answer! It should be noted that process memory in general is only really an attack surface if an attacker is able to get access to it - something that is generally not part of the threat model of a web application, unless on a shared host.
– MechMK1
2 days ago
@MechMK1 That is mentioned in the other answer already, I just wanted to add the official recommendation, too.
– Vivelin
2 days ago
@MechMK1 That is mentioned in the other answer already, I just wanted to add the official recommendation, too.
– Vivelin
2 days ago
The quoted part says nothing about recommending against using SecureString. Could you please quote (or bold) the relevant parts.
– Andrew Savinykh
2 days ago
The quoted part says nothing about recommending against using SecureString. Could you please quote (or bold) the relevant parts.
– Andrew Savinykh
2 days ago
2
2
@AndrewSavinykh It's in the first link and doesn't really say more than that they don't recommend it for new development and contains a link to the quoted part.
– Vivelin
yesterday
@AndrewSavinykh It's in the first link and doesn't really say more than that they don't recommend it for new development and contains a link to the quoted part.
– Vivelin
yesterday
@AndrewSavinykh I assume because it's a huge pain to work with, and in the end it has to end up in plaintext anyways, so there is little use to it
– MechMK1
yesterday
@AndrewSavinykh I assume because it's a huge pain to work with, and in the end it has to end up in plaintext anyways, so there is little use to it
– MechMK1
yesterday
|
show 1 more comment
Jeff is a new contributor. Be nice, and check out our Code of Conduct.
Jeff is a new contributor. Be nice, and check out our Code of Conduct.
Jeff is a new contributor. Be nice, and check out our Code of Conduct.
Jeff is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- 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%2fsecurity.stackexchange.com%2fquestions%2f215554%2fhow-to-avoid-using-system-string-with-rfc2898derivebytes-in-c%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
