จะใช้ URL สุ่มแทนรหัสผ่านได้หรือไม่ [ปิด]

12

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

ปิดให้บริการใน7 ปีที่ผ่านมา

ถือว่าปลอดภัยหรือไม่ที่จะใช้ URL ที่สร้างขึ้นจากตัวอักษรแบบสุ่ม?

http://example.com/EU3uc654/Photos

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

ฉันได้ตั้งค่าไฟล์. htaccess เพียงเพื่อแจ้งให้ทราบว่าการคลิกhttp://user:pass@url/ลิงก์ไม่สามารถทำงานได้ดีกับเบราว์เซอร์ / ไคลเอนต์อีเมลบางส่วนการแสดงข้อความโต้ตอบและข้อความเตือนที่ทำให้ผู้ใช้ที่ไม่ได้ใช้คอมพิวเตอร์สับสน

— สตูว์
แหล่งที่มา

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

— Andrew Smith

1

ฉันได้ลองทำสิ่งนี้เป็นการทดลองหลายครั้งและทุกครั้งที่มีการเชื่อมโยงกับเครื่องมือค้นหา ฉันไม่รู้ว่า แต่ฉันรู้ว่ามันเกิดขึ้น

— David Schwartz

คุณอาจต้องการกำหนดค่า SSL เพื่อหยุดคำเตือนคุณสามารถรับ certs ฟรีจากstartssl.comและ SSL นั้นไม่ต้องใช้การคำนวณอีกต่อไป (ตราบใดที่การกำหนดค่าถูกต้อง)

— Hubert Kario

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

— Chris S

17

ไม่ว่าจะเป็น "โอเค" หรือไม่ขึ้นอยู่กับความละเอียดของภาพ

หากคุณไม่ได้ใช้ SSL URL, HTML และรูปภาพจะถูกแคชไว้ในคอมพิวเตอร์ของผู้ใช้ สิ่งนี้อาจรั่ว แต่ฉันคิดว่ามันไม่น่าเป็นไปได้

แถบเครื่องมือของเบราว์เซอร์โดยเฉพาะอย่างยิ่งที่ทำโดย บริษัท ที่รันซอฟต์แวร์รวบรวมข้อมูลเช่น Alexa และ Netcraft สามารถรายงาน URL ที่เยี่ยมชมกลับไปยังไซต์แม่ของพวกเขาพร้อมให้บอทมาและรวบรวมข้อมูลในภายหลัง

การตรวจสอบความถูกต้องที่เหมาะสมเช่น HTTP auth หรือตัวแปร POST ไม่ควรทำการแคชด้วยวิธีนี้หรือรายงานกลับไปยังเว็บไซต์แม่

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

— Ladadadada
แหล่งที่มา

+1 สำหรับการพูดถึงแถบเครื่องมือของเบราว์เซอร์

— Hubert Kario

23

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

— user9517
แหล่งที่มา

10

รหัสผ่านทั้งหมดไม่ใช่แค่การรักษาความปลอดภัยผ่านความสับสนงั้นเหรอ?

— Winston Ewert

4

@ WinstonEwert: รหัสผ่านตัวเองนั้นไม่เกี่ยวกับความปลอดภัยผ่านความสับสนซึ่งเกี่ยวข้องกับความลับของการออกแบบ / การนำไปใช้ ในกรณีของ Apache auth พื้นฐานการออกแบบ / การนำไปใช้นั้นเปิดให้ทุกคนได้เห็นอย่างเต็มที่

— user9517

10

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

— Bron Gondwana

1

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

— Hubert Kario

4

คุณบอกว่าความปลอดภัยผ่านความสับสน "เกี่ยวข้องกับความลับของการออกแบบ / การนำไปใช้" แต่ชัดเจน URL แบบสุ่มไม่เกี่ยวข้องกับความลับของการออกแบบ / การใช้งาน ดังนั้น URL แบบสุ่มไม่ว่าข้อบกพร่องของพวกเขาจะไม่สามารถจัดเป็นความปลอดภัยผ่านความสับสน

— Winston Ewert

6

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

และระวังการสุ่มของตัวสร้างของคุณแน่นอน

ฉันเดาว่าคุณไม่ต้องการความปลอดภัยสูงมากที่นี่

— บรอนกอนดวานา
แหล่งที่มา

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

— Manuel Faux

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

— David Schwartz

5

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

ฉันขอแนะนำให้ใช้ระบบการรับรองความถูกต้อง. htaccess แบบง่ายแทนหรือเพิ่มเติมจากสิ่งที่คุณเสนอ

— John Gardeniers
แหล่งที่มา

5

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

ISP ของผู้เข้าชม มีการรวบรวมการเข้าชม HTTP, ข้อมูล, และบางครั้งก็ขายให้กับบุคคลที่สามโดย ISP
ที่เก็บข้อมูลบนคลาวด์ของผู้เข้าชม มีบริการจำนวนมากที่เก็บบุ๊กมาร์กและประวัติฟรีเพื่อซิงค์กับการติดตั้งเบราว์เซอร์ หากพวกเขาไม่เข้ารหัสข้อมูลล่วงหน้าอย่างที่ Mozilla ทำแนวทางการขุดข้อมูลแบบเดียวกันก็อาจบอกเป็นนัยได้

YMMV

— korkman
แหล่งที่มา

โอ้ใช่ - หรือเพียงแค่ปลั๊กอินเบราว์เซอร์ที่ค้นหาไซต์ที่เกี่ยวข้องหรืออนุญาตให้ผู้ใช้แบ่งปันบันทึกเกี่ยวกับหน้าเว็บ

— Bron Gondwana

2

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

ฉันเพิ่งกำหนดให้ผู้ใช้แต่ละรายมีการประทับเวลาที่หมดอายุและ MD5 ของอีเมลของพวกเขา

ดังนั้น URL ดูเหมือนว่า:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

หากผู้ใช้ป้อนอีเมล user@gmail.com ก่อนวันที่ 30 กรกฎาคมพวกเขายินดีที่จะไป

ไม่ได้มีความปลอดภัยระดับทหาร แต่ก็ทำงานได้ดี

— เดฟ e
แหล่งที่มา

0

ช่องโหว่นี้ใช้ช่องโหว่เดียวกันกับการจัดเก็บ sessionID ใน URL มีคนบางคนสามารถคัดลอกลิงก์ไปยังคนอื่นโดยไม่ได้ตั้งใจลืมเซ็นเซอร์ในภาพหน้าจอหรือปล่อยให้ใครบางคนมองมันเพราะมันไม่ได้ระบุรหัสผ่านเหมือนดอกจัน

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

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

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

แก้ไข: เพิ่มหรือไม่ DO_NOT_SHARE_THIS_LINK ไปที่ URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photo?DO_NOT_SHARE_THIS_LINK

นั่นคือสิ่งที่ Kongregate ทำเมื่อฝังเกมไว้ที่อื่น (ใส่ข้อมูลรับรองความถูกต้องใน URL ของเฟรม) BTW, Kongregate ยังใช้ลิงก์ผู้เยี่ยมชมสำหรับเกมที่ไม่เผยแพร่เช่นเดียวกับที่คุณต้องการใช้

— Markus von Broady
แหล่งที่มา

ที่จริงแล้วมันแย่กว่านั้นคือ ID ของเซสชันเนื่องจากเซสชันหมดอายุหลังจากผ่านไประยะหนึ่ง เอ็นจินการค้นหาการดึงข้อมูล ID เซสชันที่เข้าสู่ระบบมักจะจบลงด้วยการนำเสนอลิงค์ที่ไม่ทำงาน / ไม่ได้เข้าสู่ระบบในผลลัพธ์ หรือหากเซิร์ฟเวอร์ไม่สนใจอาจซิงค์เซสชันของผู้ใช้จำนวนมากและเมื่อหนึ่งในนั้นเข้าสู่ระบบพวกเขาทั้งหมดทำ อย่างไรก็ตามไม่เลวเท่า URL เข้าสู่ระบบถาวร :-)

— korkman

แน่นอนว่ามันแย่กว่านั้นและคุณอาจจำ IP ในเซสชันได้เนื่องจากคุณต้องลงชื่อเข้าใช้ก่อนเพื่อรับ sessid ใน url และจากนั้นคุณสามารถทำลายเซสชันได้หาก IP เปลี่ยน

— Markus von Broady