การซ่อนรหัสผ่านในเชลล์สคริปต์

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

ฉันมีวิธีเดียว: วางรหัสผ่านในไฟล์และทำให้ไฟล์นั้นถูกซ่อนและไม่มีใครเข้าถึงไฟล์ได้ (เปลี่ยนการอนุญาตและใช้ไฟล์ในสคริปต์ขณะกำลังเข้าถึงฐานข้อมูล)

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

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

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

ข้อ จำกัด เหล่านี้จำเป็นต้องมีการใช้งานในฝั่ง DB- เซิร์ฟเวอร์ของระบบเพื่อให้แม้ว่าฝั่งไคลเอ็นต์จะถูกบุกรุกข้อ จำกัด ไม่สามารถเปลี่ยนแปลงได้ (และแน่นอนว่าเซิร์ฟเวอร์ DB จำเป็นต้องได้รับการปกป้องด้วยไฟร์วอลล์ ฯลฯ นอกเหนือจากการกำหนดค่า DB ... )

ในกรณีของบัญชี DB ที่อนุญาตให้เข้าถึงแบบอ่านอย่างเดียวอย่าง จำกัด และจากที่อยู่ IP เฉพาะคุณอาจไม่ต้องการข้อมูลประจำตัวเพิ่มเติมนอกเหนือจากนั้นขึ้นอยู่กับความไวของข้อมูลและความปลอดภัยของโฮสต์ของสคริปต์ กำลังถูกเรียกใช้จาก ตัวอย่างหนึ่งอาจเป็นแบบฟอร์มการค้นหาบนเว็บไซต์ของคุณซึ่งสามารถเรียกใช้กับผู้ใช้ที่ได้รับอนุญาตให้ใช้ขั้นตอนการจัดเก็บที่ดึงเฉพาะข้อมูลที่จะนำเสนอบนหน้าเว็บเท่านั้น ในกรณีนี้การเพิ่มรหัสผ่านไม่ได้มอบความปลอดภัยพิเศษใด ๆ เนื่องจากข้อมูลนั้นได้รับการเปิดเผยสู่สาธารณะแล้วและผู้ใช้ไม่สามารถเข้าถึงข้อมูลอื่น ๆ ที่จะมีความอ่อนไหวมากขึ้น

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

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

ประการที่สี่พิจารณาเงื่อนไขที่สคริปต์จะทำงาน:

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

หากเรียกใช้จากเว็บเซิร์ฟเวอร์ให้พิจารณาตั้งค่าข้อมูลรับรองในเวลาที่คุณเริ่มเว็บเซิร์ฟเวอร์ ตัวอย่างที่ดีที่นี่คือใบรับรอง SSL - มีใบรับรองสาธารณะและรหัสส่วนตัวและรหัสส่วนตัวมีรหัสผ่าน คุณสามารถเก็บรหัสส่วนตัวบนเว็บเซิร์ฟเวอร์ แต่คุณยังต้องป้อนรหัสผ่านเมื่อคุณเริ่ม Apache คุณสามารถมีข้อมูลประจำตัวของฮาร์ดแวร์บางประเภทเช่นการ์ดจริงหรือ HSM ที่สามารถลบหรือล็อคได้เมื่อเซิร์ฟเวอร์เริ่มทำงาน (แน่นอนข้อเสียของวิธีนี้คือเซิร์ฟเวอร์ไม่สามารถรีสตาร์ทด้วยตัวเองถ้ามีอะไรเกิดขึ้นฉันอยากจะเสี่ยงกับการที่ระบบของฉันถูกบุกรุก แต่ระยะทางของคุณอาจแตกต่างกัน ... )

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

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

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

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

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

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

มิฉะนั้นแนวคิดของคุณในการวางรหัสผ่านในไฟล์แยกต่างหากที่มีสิทธิ์แบบ จำกัด นั้นค่อนข้างมาก คุณสามารถยกตัวอย่างแหล่งที่มาของไฟล์จากสคริปต์หลัก:

. /usr/local/etc/secret-password-here

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

คำตอบอื่น ๆ ได้จ่าหน้าว่าแต่ฉันจะพิจารณาว่า ขึ้นอยู่กับชนิดของฐานข้อมูลที่ผู้ใช้ของคุณกำลังเชื่อมต่อคุณอาจมีกลไกที่เหมาะสมซึ่งโปรแกรมไคลเอนต์เหล่านั้นใช้อยู่แล้วซึ่งในกรณีนี้ต้องแน่ใจว่าใช้พวกเขา (ฉันกำลังคิดถึง~/.mysqlrcหรือ~/.pgpass)

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

ถ้าไม่มีหลีกเลี่ยงการดังกล่าวข้างต้นที่คุณจำเป็นต้องเก็บข้อมูลประจำตัว, แล้วอ่านคำตอบอื่น ๆ ที่นี่

ความคิดของคุณเกี่ยวกับการซ่อนรหัสผ่านในสถานที่ที่ไม่สามารถเข้าถึงได้อาจใช้ได้ขึ้นอยู่กับสถานการณ์

หากข้อมูลแยกจากกันนั่นหมายถึงการแก้ไขไฟล์อย่างง่ายเช่นระหว่างการตรวจสอบโค้ดกับเพื่อนร่วมงานจะไม่แสดงขึ้นมา แต่ตระหนักว่าทุกคนที่สามารถเข้าถึงบัญชีของคุณสามารถค้นหาไฟล์ดังกล่าวได้อย่างง่ายดาย ฉันใช้ไดเรกทอรีย่อยของ~/.sshเพื่อวัตถุประสงค์ดังกล่าวด้วยเหตุผลง่ายๆที่sshบ่นว่าสิทธิ์การเข้าถึง~/.sshนั้นไม่ถูก จำกัด เพียงพอ

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

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

ใช้ GPG :

ดีกว่าเล็กน้อย แต่ก็ยังไม่สามารถพิสูจน์การโจมตีโดยผู้ใช้รูทบนระบบของคุณได้คือการเข้ารหัสชื่อผู้ใช้ / รหัสผ่านคู่ในไฟล์gpgสาธารณะของคุณและให้สคริปต์เรียกเนื้อหาในไฟล์ (อาจเป็นไปได้เพื่อให้คุณใส่รหัส เก็บไว้ชั่วคราว / หมดอายุ) ฉันใช้การ์ด ggp เพื่อที่ว่าเมื่อฉันออกจากแล็ปท็อปไปรอบ ๆ แต่ดึงการ์ดออกมาจะไม่สามารถเข้าถึงได้แม้ว่าหมุดจะยังคงถูกแคชอยู่ อย่างน้อยถ้าฉันวิ่ง 20 ครั้งในเวลาไม่กี่นาทีฉันต้องเตรียมพินเพียงครั้งเดียว

ความปลอดภัยดูเหมือนจะเกี่ยวข้องกับความสะดวกสบายในทางกลับกันเสมอ (การตั้งค่าและใช้งาน)

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

http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm

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

การติดตั้ง:

1. wget link-to-the-zip-file

2. แตกไฟล์ zip ที่ดาวน์โหลดมาใหม่

3. cd / tmp / KingLazySHIELD

4. ./install.sh / var / tmp / KINGLAZY / SHIELDX- (ชื่อสคริปต์ของคุณ) / home / (ชื่อผู้ใช้ของคุณ) - บังคับใช้

สิ่งที่คำสั่งติดตั้งข้างต้นจะทำเพื่อคุณคือ:

1. มันจะติดตั้งสคริปต์ที่เข้ารหัสรุ่นในไดเรกทอรี / var / tmp / KINGLAZY / SHIELDX- (your-script-name)

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

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

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

บันทึก:

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

อีกวิธีหนึ่งโดยไม่คำนึงถึงความปลอดภัย (ฉันคิดว่ามันเป็นการดีกว่าที่จะเก็บข้อมูลประจำตัวในไฟล์อื่นหรือในฐานข้อมูล) คือการเข้ารหัสรหัสผ่านด้วย gpg และใส่ไว้ในสคริปต์

ฉันใช้คู่คีย์ gpg แบบไม่ใช้รหัสผ่านที่ฉันเก็บไว้ใน usb (หมายเหตุ: เมื่อคุณส่งออกคู่คีย์นี้ไม่ได้ใช้ - ชุดเกราะให้ส่งออกคู่ในรูปแบบไบนารี)

เข้ารหัสรหัสผ่านของคุณก่อน:

echo -n "pAssw0rd" | gpg --armor --no-default-keyring --keyring /media/usb/key.pub --recipient someone@mail.com --encrypt

ที่จะพิมพ์รหัสผ่านที่เข้ารหัส gpg ในเอาต์พุตมาตรฐาน คัดลอกข้อความทั้งหมดและเพิ่มลงในสคริปต์:

password=$(gpg --batch --quiet --no-default-keyring --secret-keyring /media/usb/key.priv --decrypt <<EOF 
-----BEGIN PGP MESSAGE-----

hQEMA0CjbyauRLJ8AQgAkZT5gK8TrdH6cZEy+Ufl0PObGZJ1YEbshacZb88RlRB9
h2z+s/Bso5HQxNd5tzkwulvhmoGu6K6hpMXM3mbYl07jHF4qr+oWijDkdjHBVcn5
0mkpYO1riUf0HXIYnvCZq/4k/ajGZRm8EdDy2JIWuwiidQ18irp07UUNO+AB9mq8
5VXUjUN3tLTexg4sLZDKFYGRi4fyVrYKGsi0i5AEHKwn5SmTb3f1pa5yXbv68eYE
lCVfy51rBbG87UTycZ3gFQjf1UkNVbp0WV+RPEM9JR7dgR+9I8bKCuKLFLnGaqvc
beA3A6eMpzXQqsAg6GGo3PW6fMHqe1ZCvidi6e4a/dJDAbHq0XWp93qcwygnWeQW
Ozr1hr5mCa+QkUSymxiUrRncRhyqSP0ok5j4rjwSJu9vmHTEUapiyQMQaEIF2e2S
/NIWGg==
=uriR
-----END PGP MESSAGE-----
EOF)

ด้วยวิธีนี้ก็ต่อเมื่อมีการติดตั้ง usb ในระบบรหัสผ่านสามารถถอดรหัสได้ แน่นอนคุณสามารถนำเข้ากุญแจเข้าสู่ระบบ (ความปลอดภัยน้อยลงหรือไม่มีการรักษาความปลอดภัยเลย) หรือคุณสามารถป้องกันรหัสส่วนตัวด้วยรหัสผ่าน (ดังนั้นจึงไม่สามารถทำงานอัตโนมัติ)

#!/bin/bash
unset username
unset password
unset dbname
echo -n "username:"
read username
echo -n "dbname:"
read dbname
prompt="password:"

    while IFS= read -p "$prompt" -r -s -n 1 char
            do
                    if [[ $char == $'\0' ]]
                            then
                                    break
                    fi
                    prompt='*'
                    password+="$char"
            #       read -s -p "Enter Password: "  pswd
            #       echo -e "\nYour password is: " $pswd
            done

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