เมื่อใดที่ฉันจะต้องใช้ SecureString ใน. NET


179

ฉันพยายามที่จะทำให้วัตถุประสงค์ของ SecureString ของ. NET จาก MSDN:

อินสแตนซ์ของคลาส System.String มีทั้งที่ไม่เปลี่ยนรูปและเมื่อไม่ต้องการอีกต่อไปไม่สามารถกำหนดตารางเวลาทางโปรแกรมสำหรับการรวบรวมขยะ นั่นคืออินสแตนซ์จะอ่านอย่างเดียวหลังจากที่มันถูกสร้างขึ้นและเป็นไปไม่ได้ที่จะทำนายว่าเมื่อใดที่อินสแตนซ์นั้นจะถูกลบออกจากหน่วยความจำคอมพิวเตอร์ ดังนั้นหากวัตถุ String มีข้อมูลที่ละเอียดอ่อนเช่นรหัสผ่านหมายเลขบัตรเครดิตหรือข้อมูลส่วนบุคคลมีความเสี่ยงที่ข้อมูลจะถูกเปิดเผยหลังจากใช้งานเพราะแอปพลิเคชันของคุณไม่สามารถลบข้อมูลออกจากหน่วยความจำคอมพิวเตอร์

วัตถุ SecureString คล้ายกับวัตถุ String ซึ่งมีค่าข้อความ อย่างไรก็ตามค่าของวัตถุ SecureString จะถูกเข้ารหัสโดยอัตโนมัติสามารถแก้ไขได้จนกว่าแอปพลิเคชันของคุณจะทำเครื่องหมายว่าเป็นแบบอ่านอย่างเดียวและสามารถลบได้จากหน่วยความจำคอมพิวเตอร์โดยแอปพลิเคชันของคุณหรือตัวรวบรวมขยะ. NET Framework

ค่าของอินสแตนซ์ของ SecureString จะถูกเข้ารหัสโดยอัตโนมัติเมื่อเริ่มต้นอินสแตนซ์หรือเมื่อมีการปรับเปลี่ยนค่า แอปพลิเคชันของคุณสามารถแสดงผลอินสแตนซ์ไม่เปลี่ยนรูปและป้องกันการแก้ไขเพิ่มเติมโดยการเรียกใช้เมธอด MakeReadOnly

การเข้ารหัสอัตโนมัติเป็นการจ่ายผลตอบแทนมหาศาลหรือไม่?

และทำไมฉันไม่สามารถพูดได้:

SecureString password = new SecureString("password");

แทน

SecureString pass = new SecureString();
foreach (char c in "password".ToCharArray())
    pass.AppendChar(c);

SecureString ด้านใดที่ฉันขาดหายไป


3
11 ปีต่อมาและ MS ไม่แนะนำSecureStringให้พัฒนาใหม่อีกต่อไป: github.com/dotnet/platform-compat/blob/master/docs/DE0001.md
Matt Thomas

คำตอบ:


4

ฉันจะหยุดใช้ SecureString ดูเหมือนว่า PG พวกนั้นกำลังลดการสนับสนุน อาจเป็นไปได้ดึงมันในอนาคต - https://github.com/dotnet/apireviews/tree/master/2015-07-14-securestring

เราควรลบการเข้ารหัสจาก SecureString ในทุกแพลตฟอร์มใน. NET Core - เราควรใช้ SecureString ที่ล้าสมัย - เราอาจไม่ควรเปิดเผย SecureString ใน. NET Core


1
การเชื่อมโยงจะตาย แต่ดูเหมือนว่าจะดำเนินการต่อไป: docs.microsoft.com/en-us/dotnet/api/ ...... .. พร้อมกับคำแนะนำที่อ่อนแอมากเกี่ยวกับเส้นทางไปข้างหน้า execpt "อย่าใช้ข้อมูลประจำตัว" - github.com/dotnet/platform- compat / blob / master / docs / DE0001.md .. คุณไม่กล้าใช้รหัสผ่านเพื่อปกป้องรหัสส่วนตัวของใบรับรองของคุณ!
felickz

1
หลังจาก 11 ปีคำตอบนี้ดูเหมือนจะเป็นคำใหม่ที่ถูกต้อง ลิงค์ดูเหมือนจะค้าง แต่คำแนะนำจาก MS คือ: ไม่ควรใช้ SecureString
Richard Morgan

109

บางส่วนของกรอบงานที่ใช้ในปัจจุบันSecureString:

จุดประสงค์หลักคือเพื่อลดพื้นที่การโจมตีแทนที่จะกำจัดมัน SecureStringsถูก "ตรึง" ไว้ใน RAM ดังนั้น Garbage Collector จะไม่ย้ายไปไหนมาไหนหรือทำสำเนา นอกจากนี้ยังทำให้แน่ใจว่าข้อความธรรมดาจะไม่ถูกเขียนลงในไฟล์ Swap หรือในคอร์ทิ้ง การเข้ารหัสนั้นเหมือนการทำให้งงงวยและจะไม่หยุดการแฮ็กเกอร์ที่กำหนด แต่ใครจะสามารถหาคีย์สมมาตรที่ใช้ในการเข้ารหัสและถอดรหัส

อย่างที่คนอื่นพูดเหตุผลที่คุณต้องสร้างSecureStringตัวละครทีละตัวเป็นเพราะข้อบกพร่องที่เห็นได้ชัดครั้งแรกของการทำอย่างอื่น: คุณคงมีค่าความลับเป็นสตริงธรรมดาแล้วสิ่งที่จุด?

SecureStrings เป็นขั้นตอนแรกในการแก้ปัญหาไก่และไข่ดังนั้นแม้ว่าสถานการณ์ปัจจุบันส่วนใหญ่ต้องการแปลงพวกเขากลับมาเป็นสายปกติเพื่อใช้ประโยชน์จากพวกเขาเลยการมีอยู่ของพวกเขาในกรอบนี้หมายถึงการสนับสนุนที่ดีกว่าสำหรับพวกเขา ในอนาคต - อย่างน้อยก็ถึงจุดที่โปรแกรมของคุณไม่จำเป็นต้องเป็นลิงก์ที่อ่อนแอ


2
ฉันวิ่งข้ามมันดูคุณสมบัติรหัสผ่านของ ProcessStartInfo ไม่แม้แต่จะสนใจกับประเภทนี้ฉันเพิ่งตั้งเป็นสตริงปกติจนกระทั่งคอมไพเลอร์เห่ามาที่ฉัน
Richard Morgan

มันเป็นนิสัยจะหาง่ายคีย์การเข้ารหัสแบบสมมาตรตั้งแต่ SecureString จะขึ้นอยู่กับ DPAPI ซึ่งไม่ว่าการจัดเก็บที่สำคัญใน plaintext แล้ว ...
Avid

1
นอกจากนี้มันไม่ได้เป็นปัญหาไก่และไข่มากนักเนื่องจากมันไม่ใช่สิ่งทดแทนการเข้ารหัสในที่เก็บข้อมูล แต่เป็นวิธีแก้ปัญหาสำหรับสายอักขระ. NET ที่ไม่เปลี่ยนแปลงและมีการจัดการ
AviD

2
"คุณน่าจะมีค่าลับเป็นสตริงธรรมดาอยู่แล้วดังนั้นประเด็นคืออะไร" มีคำตอบสำหรับคำถามนี้หรือไม่? ดูเหมือนว่าที่สุดแล้วมันเป็นทางออกที่ "ดีกว่าไม่มีอะไร" ถ้าคุณตั้งใจจะเก็บรหัสผ่านไว้ในหน่วยความจำเป็นระยะเวลานาน
xr280xr

2
สิ่งที่เกี่ยวกับการมีตัวอย่างรหัสง่าย ๆ ของการใช้งาน? ฉันเชื่อว่าฉันจะเข้าใจได้ดีขึ้นว่าจะใช้อย่างไรและเมื่อใด
codea

37

แก้ไข : อย่าใช้ SecureString

คำแนะนำปัจจุบันขณะนี้บอกว่าไม่ควรใช้คลาส รายละเอียดสามารถดูได้ที่ลิงค์นี้: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md

จากบทความ:

DE0001: ไม่ควรใช้ SecureString

แรงจูงใจ

  • วัตถุประสงค์SecureStringคือเพื่อหลีกเลี่ยงการเก็บความลับในหน่วยความจำกระบวนการเป็นข้อความธรรมดา
  • อย่างไรก็ตามแม้กระทั่งบน Windows SecureStringก็ยังไม่มีแนวคิด OS
    • มันทำให้หน้าต่างทำให้ข้อความธรรมดาสั้นลง มันไม่ได้ป้องกันอย่างเต็มที่เนื่องจาก. NET ยังคงต้องแปลงสตริงเป็นการแสดงข้อความธรรมดา
    • ประโยชน์คือการแสดงข้อความธรรมดาไม่ได้แขวนเป็นตัวอย่างของSystem.String- อายุการใช้งานของบัฟเฟอร์พื้นเมืองจะสั้นกว่า
  • เนื้อหาของอาร์เรย์ไม่มีการเข้ารหัสยกเว้นใน. NET Framework
    • ใน. NET Framework เนื้อหาของอาร์เรย์ภายในจะถูกเข้ารหัส .NET ไม่รองรับการเข้ารหัสในทุกสภาพแวดล้อมไม่ว่าจะเกิดจาก API ที่ขาดหายไปหรือปัญหาการจัดการคีย์

คำแนะนำ

อย่าใช้SecureStringรหัสใหม่ เมื่อทำการย้ายรหัสไปยัง. NET Core ให้พิจารณาว่าเนื้อหาของอาร์เรย์นั้นไม่ได้เข้ารหัสในหน่วยความจำ

วิธีการทั่วไปในการจัดการกับข้อมูลรับรองคือการหลีกเลี่ยงและใช้วิธีการอื่นในการตรวจสอบสิทธิ์เช่นการรับรองความถูกต้องของ Windows

สิ้นสุดการแก้ไข: สรุปต้นฉบับด้านล่าง

คำตอบที่ดีมากมาย นี่เป็นบทสรุปอย่างย่อของสิ่งที่ถูกกล่าวถึง

Microsoft ได้นำคลาส SecureString มาใช้เพื่อให้ความปลอดภัยที่ดีขึ้นด้วยข้อมูลที่ละเอียดอ่อน (เช่นบัตรเครดิตรหัสผ่าน ฯลฯ ) มันให้โดยอัตโนมัติ:

  • การเข้ารหัส (ในกรณีที่หน่วยความจำทิ้งหรือแคชหน้า)
  • ปักหมุดในความทรงจำ
  • ความสามารถในการทำเครื่องหมายว่าอ่านอย่างเดียว (เพื่อป้องกันการแก้ไขเพิ่มเติม)
  • การก่อสร้างที่ปลอดภัยโดยไม่อนุญาตให้ส่งผ่านค่าคงที่

ปัจจุบัน SecureString มีการใช้งาน จำกัด แต่คาดว่าจะมีการนำไปใช้ที่ดีขึ้นในอนาคต

จากข้อมูลนี้คอนสตรัคของ SecureString ไม่ควรใช้แค่สายอักขระและแบ่งเป็น char อาร์เรย์เนื่องจากมีการสะกดสตริงที่เอาชนะวัตถุประสงค์ของ SecureString

ข้อมูลเพิ่มเติม:

  • โพสต์จากการรักษาความปลอดภัย .NET บล็อกพูดคุยเกี่ยวกับมากเช่นเดียวกับครอบคลุมที่นี่
  • อีกคนหนึ่งกลับมา ทบทวนอีกครั้งและพูดถึงเครื่องมือที่สามารถทิ้งเนื้อหาของ SecureString

แก้ไข: ฉันพบว่ามันยากที่จะเลือกคำตอบที่ดีที่สุดเนื่องจากมีข้อมูลที่ดีในหลาย ๆ แย่มากไม่มีตัวเลือกคำตอบที่ช่วย


19

คำตอบสั้น ๆ

ทำไมฉันไม่สามารถพูดได้:

SecureString password = new SecureString("password");

เพราะตอนนี้คุณมีpasswordความทรงจำแล้ว มีวิธีที่จะเช็ดมัน - ซึ่งตรงจุดSecureString

คำตอบยาว ๆ

เหตุผลว่าทำไม SecureStringนั้นมีอยู่เพราะคุณไม่สามารถใช้ZeroMemoryเพื่อล้างข้อมูลที่ละเอียดอ่อนเมื่อคุณทำเสร็จแล้ว มีอยู่เพื่อแก้ไขปัญหาที่เกิดขึ้นเนื่องจาก CLR

ในปกติพื้นเมืองของแอพลิเคชันที่คุณจะเรียกSecureZeroMemory:

เติมบล็อกของหน่วยความจำด้วยเลขศูนย์

หมายเหตุ : SecureZeroMemory จะเป็นเหมือนZeroMemory, ยกเว้นคอมไพเลอร์จะไม่เพิ่มประสิทธิภาพของมันออกไป

ปัญหาคือคุณไม่สามารถโทรZeroMemoryหรือSecureZeroMemoryเข้าไปใน. NET และใน. NET strings จะไม่เปลี่ยนรูป คุณไม่สามารถเขียนทับเนื้อหาของสตริงเหมือนที่คุณสามารถทำได้ในภาษาอื่น:

//Wipe out the password
for (int i=0; i<password.Length; i++)
   password[i] = \0;

แล้วคุณจะทำอย่างไร เราจะให้ความสามารถใน. NET ในการล้างรหัสผ่านหรือหมายเลขบัตรเครดิตจากหน่วยความจำเมื่อเราทำมันได้อย่างไร

วิธีเดียวที่สามารถทำได้คือการวางสตริงในบล็อกหน่วยความจำดั้งเดิมบางที่ซึ่งคุณสามารถโทรZeroMemoryได้ วัตถุหน่วยความจำดั้งเดิมเช่น:

  • BSTR
  • HGLOBAL
  • หน่วยความจำที่ไม่มีการจัดการ CoTaskMem

SecureString ให้ความสามารถที่หายไปกลับมา

ใน. NET สตริงไม่สามารถเช็ดได้เมื่อคุณทำเสร็จแล้ว:

  • พวกมันไม่เปลี่ยนรูป คุณไม่สามารถเขียนทับเนื้อหาของพวกเขา
  • คุณไม่สามารถDisposeของพวกเขา
  • การทำความสะอาดของพวกเขาอยู่ที่ความเมตตาของนักสะสมขยะ

SecureString มีอยู่เป็นวิธีในการส่งผ่านความปลอดภัยของสายอักขระและสามารถรับประกันการล้างข้อมูลได้เมื่อคุณต้องการ

คุณถามคำถาม:

ทำไมฉันไม่สามารถพูดได้:

SecureString password = new SecureString("password");

เพราะตอนนี้คุณมีpasswordความทรงจำแล้ว ไม่มีวิธีการเช็ด มันติดอยู่ที่นั่นจนกระทั่ง CLR เกิดขึ้นเพื่อตัดสินใจใช้หน่วยความจำนั้นอีกครั้ง คุณทำให้เราย้อนกลับไปเมื่อเราเริ่ม; แอปพลิเคชันที่ทำงานด้วยรหัสผ่านที่เราไม่สามารถกำจัดได้และที่ที่หน่วยความจำดัมพ์ (หรือการตรวจสอบกระบวนการ) สามารถดูรหัสผ่าน

SecureString ใช้ Data Protection API เพื่อจัดเก็บสตริงที่เข้ารหัสในหน่วยความจำ วิธีนั้นสตริงจะไม่มีอยู่ใน swapfiles, crash dumps หรือแม้แต่ในหน้าต่างตัวแปรโลคัลที่มีเพื่อนร่วมงานมองหาคุณควร

ฉันจะอ่านรหัสผ่านได้อย่างไร

จากนั้นเป็นคำถาม: ฉันจะโต้ตอบกับสตริงได้อย่างไร คุณไม่ต้องการวิธีเช่น:

String connectionString = secureConnectionString.ToString()

เพราะตอนนี้คุณกลับมาแล้วตรงจุดที่คุณเริ่ม - รหัสผ่านที่คุณไม่สามารถกำจัดได้ คุณต้องการบังคับให้นักพัฒนาจัดการสายอักขระที่ละเอียดอ่อนได้อย่างถูกต้องเพื่อให้สามารถลบออกจากหน่วยความจำได้

นั่นคือเหตุผลที่. NET ได้จัดให้มีสามฟังก์ชั่นตัวช่วยที่มีประโยชน์ในการจัดการ SecureString ในหน่วยความจำที่ไม่มีการจัดการ

คุณแปลงสายอักขระเป็นหน่วยความจำที่ไม่มีการจัดการ blob จัดการกับมันแล้วเช็ดอีกครั้ง

APIs บางคนยอมรับSecureStrings ตัวอย่างเช่นใน ADO.net 4.5 SqlConnection.CredentialรับชุดSqlCredential :

SqlCredential cred = new SqlCredential(userid, password); //password is SecureString
SqlConnection conn = new SqlConnection(connectionString);
conn.Credential = cred;
conn.Open();

คุณสามารถเปลี่ยนรหัสผ่านภายในสตริงการเชื่อมต่อ:

SqlConnection.ChangePassword(connectionString, cred, newPassword);

และมีหลายสถานที่ใน. NET ที่พวกเขายังคงยอมรับสตริงธรรมดาสำหรับวัตถุประสงค์ในการทำงานร่วมกันได้อย่างรวดเร็วจากนั้นจึงหันไปใส่ SecureString

จะใส่ข้อความลงใน SecureString ได้อย่างไร

สิ่งนี้ยังทำให้เกิดปัญหา:

ฉันจะรับรหัสผ่านใน SecureString ตั้งแต่แรกได้อย่างไร

นี่คือความท้าทาย แต่ประเด็นคือเพื่อให้คุณคิดถึงความปลอดภัย

บางครั้งฟังก์ชั่นนี้มีให้สำหรับคุณแล้ว ตัวอย่างเช่นตัวควบคุมWPF PasswordBoxสามารถส่งคืนรหัสผ่านที่คุณป้อนเป็นSecureStringโดยตรง:

คุณสมบัติ PasswordBox.SecurePassword

ได้รับรหัสผ่านที่จัดขึ้นในขณะนี้โดยPasswordBoxเป็นSecureString

สิ่งนี้มีประโยชน์เพราะทุกที่ที่คุณเคยผ่านสายอักขระดิบคุณก็มีระบบประเภทที่บ่นว่า SecureString เข้ากันไม่ได้กับ String คุณต้องการไปให้นานที่สุดก่อนที่จะแปลง SecureString ของคุณกลับเป็นสตริงปกติ

การแปลง SecureString นั้นง่ายพอ:

  • SecureStringToBSTR
  • PtrToStringBSTR

ในขณะที่:

private static string CreateString(SecureString secureString)
{
    IntPtr intPtr = IntPtr.Zero;
    if (secureString == null || secureString.Length == 0)
    {
        return string.Empty;
    }
    string result;
    try
    {
        intPtr = Marshal.SecureStringToBSTR(secureString);
        result = Marshal.PtrToStringBSTR(intPtr);
    }
    finally
    {
        if (intPtr != IntPtr.Zero)
        {
            Marshal.ZeroFreeBSTR(intPtr);
        }
    }
    return result;
}

พวกเขาไม่ต้องการให้คุณทำ

แต่ฉันจะรับสตริงเข้าสู่ SecureString ได้อย่างไร สิ่งที่คุณต้องทำก็คือหยุดมีรหัสผ่านในStringในตอนแรก คุณต้องมีมันในอย่างอื่น แม้แต่Char[]อาเรย์ก็มีประโยชน์

นั่นคือเมื่อคุณสามารถผนวกอักขระแต่ละตัวและล้างข้อความธรรมดาเมื่อเสร็จแล้ว:

for (int i=0; i < PasswordArray.Length; i++)
{
   password.AppendChar(PasswordArray[i]);
   PasswordArray[i] = (Char)0;
}

คุณต้องใช้รหัสผ่านของคุณเก็บไว้ในหน่วยความจำบางส่วนที่คุณสามารถเช็ด โหลดลงใน SecureString จากตรงนั้น


TL; DR: SecureStringที่มีอยู่เพื่อให้เทียบเท่าของZeroMemory

บางคนไม่เห็นจุดในการลบรหัสผ่านของผู้ใช้จากหน่วยความจำเมื่ออุปกรณ์ถูกล็อคหรือเช็ดการกดแป้นพิมพ์จากหน่วยความจำหลังจากที่ได้รับการรับรองความถูกต้องแล้ว คนเหล่านั้นไม่ใช้ SecureString


14

มีสถานการณ์น้อยมากที่คุณสามารถใช้ SecureString ในเวอร์ชันปัจจุบันของ Framework ได้อย่างสมเหตุสมผล มันมีประโยชน์จริงๆสำหรับการโต้ตอบกับ API ที่ไม่มีการจัดการ - คุณสามารถจัดการมันได้โดยใช้ Marshal.SecureStringToGlobalAllocUnicode

ทันทีที่คุณแปลงเป็น / จาก System.String คุณจะต้องเสียจุดประสงค์

ตัวอย่าง MSDN สร้าง SecureString ตัวอักษรในแต่ละครั้งจากอินพุตคอนโซลและส่งผ่านสตริงที่ปลอดภัยไปยัง API ที่ไม่มีการจัดการ มันค่อนข้างซับซ้อนและไม่สมจริง

คุณอาจคาดหวังว่า. NET เวอร์ชันในอนาคตจะมีการสนับสนุนเพิ่มเติมสำหรับ SecureString ซึ่งจะทำให้มีประโยชน์มากขึ้นเช่น:

  • SecureString Console.ReadLineSecure () หรือคล้ายกันเพื่ออ่านอินพุตคอนโซลใน SecureString โดยไม่มีรหัสที่ซับซ้อนทั้งหมดในตัวอย่าง

  • WinForms TextBox แทนที่ที่เก็บคุณสมบัติ TextBox.Text เป็นสตริงที่ปลอดภัยเพื่อให้สามารถป้อนรหัสผ่านได้อย่างปลอดภัย

  • ส่วนขยายไปยัง API ที่เกี่ยวข้องกับความปลอดภัยเพื่ออนุญาตให้ส่งรหัสผ่านเป็น SecureString

หากไม่มีข้อมูลข้างต้น SecureString จะมีมูลค่า จำกัด


12

ฉันเชื่อว่าเหตุผลที่คุณต้องใส่ตัวอักษรต่อท้ายแทนการสร้างอินสแตนซ์แบนหนึ่งอันเนื่องมาจากในพื้นหลังผ่าน "รหัสผ่าน" ไปยังตัวสร้างของ SecureString ทำให้สตริง "รหัสผ่าน" นั้นในหน่วยความจำเอาชนะวัตถุประสงค์ของสตริงที่ปลอดภัย

โดยการต่อท้ายคุณจะใส่ตัวละครในแต่ละครั้งในหน่วยความจำซึ่ง likley ไม่ให้ติดกันทำให้ร่างกายยากขึ้นมากในการสร้างสตริงเดิม ฉันอาจจะผิดที่นี่ แต่นั่นเป็นวิธีที่อธิบายให้ฉัน

วัตถุประสงค์ของการเรียนคือการป้องกันไม่ให้ข้อมูลที่ปลอดภัยถูกเปิดเผยผ่านการถ่ายโอนข้อมูลหน่วยความจำหรือเครื่องมือที่คล้ายกัน


11

MS พบว่าในบางกรณีที่ทำให้เซิร์ฟเวอร์ (เดสก์ท็อป) เกิดความผิดพลาดมีบางครั้งที่สภาพแวดล้อมรันไทม์จะถ่ายโอนข้อมูลหน่วยความจำที่เปิดเผยเนื้อหาของสิ่งที่อยู่ในหน่วยความจำ Secure String เข้ารหัสไว้ในหน่วยความจำเพื่อป้องกันไม่ให้ผู้โจมตีสามารถเรียกเนื้อหาของสตริงได้


5

ข้อดีอย่างหนึ่งของ SecureString ก็คือควรหลีกเลี่ยงความเป็นไปได้ที่ข้อมูลของคุณจะถูกเก็บไว้ในดิสก์เนื่องจากการแคชหน้า หากคุณมีรหัสผ่านในหน่วยความจำแล้วโหลดโปรแกรมหรือชุดข้อมูลขนาดใหญ่รหัสผ่านของคุณอาจถูกเขียนลงในไฟล์ swap เนื่องจากโปรแกรมของคุณได้รับการจัดหน้าหน่วยความจำไม่เพียงพอ ด้วย SecureString อย่างน้อยข้อมูลจะไม่ได้วนรอบบนดิสก์ของคุณในข้อความที่ชัดเจน


4

ฉันเดาว่าเป็นเพราะสตริงนั้นมีความปลอดภัยเช่นแฮกเกอร์ไม่ควรอ่าน หากคุณเริ่มต้นด้วยสตริงแฮ็กเกอร์สามารถอ่านสตริงเดิม


4

ในฐานะที่เป็นรัฐคำอธิบายค่าจะถูกเก็บไว้เข้ารหัสด้วยหมายความว่าการถ่ายโอนข้อมูลหน่วยความจำของกระบวนการของคุณจะไม่เปิดเผยค่าของสตริง

เหตุผลที่คุณไม่สามารถสร้าง SecureString จากสตริงคงที่ก็เพราะคุณจะมีสตริงที่ไม่ได้เข้ารหัสในหน่วยความจำ การ จำกัด ให้คุณสร้างสตริงเป็นชิ้น ๆ ช่วยลดความเสี่ยงในการมีสตริงทั้งหมดในหน่วยความจำพร้อมกัน


2
หากพวกเขากำลัง จำกัด การก่อสร้างจากสตริงคงที่แล้วบรรทัด foreach (อักขระ c ใน "รหัสผ่าน". ToCharArray ()) จะพ่ายแพ้ที่ไม่? มันควรเป็นรหัสผ่านภาคผนวก ('p'); pass.AppendChar ( 'a'); etc?
Richard Morgan

ใช่คุณสามารถละทิ้งการป้องกันเล็กน้อยได้อย่างง่ายดาย SecureString ให้คุณ พวกเขากำลังพยายามทำให้เป็นเรื่องยากที่จะยิงตัวเองอย่างสมบูรณ์ด้วยการเดินเท้า เห็นได้ชัดว่าต้องมีวิธีในการรับค่าเข้าและออกจาก SecureString หรือคุณไม่สามารถใช้เพื่ออะไร
Mark Bessey

1

อีกกรณีการใช้งานคือเมื่อคุณทำงานกับแอปพลิเคชันการชำระเงิน (POS) และคุณไม่สามารถใช้โครงสร้างข้อมูลที่ไม่เปลี่ยนรูปแบบเพื่อเก็บข้อมูลที่ละเอียดอ่อนเพราะคุณเป็นนักพัฒนาที่ระมัดระวัง ตัวอย่างเช่น: หากฉันจะเก็บข้อมูลบัตรที่ละเอียดอ่อนหรือข้อมูลเมตาการอนุญาตลงในสตริงที่ไม่เปลี่ยนรูปจะมีกรณีเกิดขึ้นเสมอเมื่อข้อมูลนี้จะมีอยู่ในหน่วยความจำตามจำนวนครั้งที่สำคัญหลังจากที่ถูกทิ้ง ฉันไม่สามารถเขียนทับมันได้ ข้อดีอีกอย่างหนึ่งที่ข้อมูลสำคัญถูกเก็บไว้ในหน่วยความจำเข้ารหัส

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.