คำถามติดแท็ก security

ฉันออกแบบฟังก์ชั่นที่อาจรับ / ตั้งค่าทรัพยากรจาก SD และหากไม่พบจาก sd ให้นำจากสินทรัพย์และถ้าเป็นไปได้ให้เขียนเนื้อหากลับไปที่ SD ฟังก์ชันนี้อาจตรวจสอบโดยการเรียกใช้เมธอดหากติดตั้ง SD และเข้าถึงได้ ... boolean bSDisAvalaible = Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED); ฟังก์ชั่นที่ออกแบบของฉันอาจถูกใช้จากแอพ (โปรเจ็กต์) หนึ่งไปยังอีกแอพหนึ่ง (มีหรือไม่มี android.permission.WRITE_EXTERNAL_STORAGE) จากนั้นฉันต้องการตรวจสอบว่าแอปพลิเคชันปัจจุบันได้รับอนุญาตโดยไม่ต้องเล่นกับ SecurityException หรือไม่ มีวิธีที่ "ดี" ในการศึกษาสิทธิ์ที่กำหนดไว้ในขณะรันไทม์หรือไม่?

93 android  security  permissions  runtime 

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

93 api  security  authentication  api-key  secret-key 

Firebase มี back-end ของฐานข้อมูลเพื่อให้นักพัฒนาสามารถมุ่งเน้นไปที่โค้ดฝั่งไคลเอ็นต์ ดังนั้นหากมีคนใช้ firebase uri ของฉัน (ตัวอย่างเช่นhttps://firebaseinstance.firebaseio.com) ให้พัฒนาขึ้นในเครื่อง จากนั้นพวกเขาจะสามารถสร้างแอปอื่นจากอินสแตนซ์ Firebase สมัครใช้งานและตรวจสอบสิทธิ์ตัวเองเพื่ออ่านข้อมูลทั้งหมดของแอป Firebase ของฉันได้หรือไม่

93 security  firebase 

ฉันได้อ่านเอกสารที่เกี่ยวข้องกับปัญหานี้มากมาย แต่ฉันยังไม่สามารถรวบรวมทุกส่วนเข้าด้วยกันได้ดังนั้นฉันจึงอยากถามคำถามสองสามข้อ ก่อนอื่นฉันจะอธิบายสั้น ๆ เกี่ยวกับขั้นตอนการรับรองความถูกต้องตามที่ฉันเข้าใจเนื่องจากฉันอาจเข้าใจผิดในเรื่องนั้น: ไคลเอนต์เริ่มการเชื่อมต่อซึ่งเซิร์ฟเวอร์ตอบสนองด้วยการรวมกันของคีย์สาธารณะข้อมูลเมตาและลายเซ็นดิจิทัลของ ผู้มีอำนาจที่เชื่อถือได้ จากนั้นไคลเอ็นต์จะตัดสินใจว่าเธอเชื่อถือเซิร์ฟเวอร์หรือไม่เข้ารหัสคีย์เซสชันแบบสุ่มด้วยคีย์สาธารณะและส่งกลับ รหัสเซสชันนี้สามารถถอดรหัสได้ด้วยคีย์ส่วนตัวที่เก็บไว้บนเซิร์ฟเวอร์เท่านั้น เซิร์ฟเวอร์ทำสิ่งนี้แล้วเซสชัน HTTPS จะเริ่มขึ้น ดังนั้นถ้าฉันพูดถูกต้องข้างต้นคำถามคือการโจมตีแบบคนตรงกลางสามารถเกิดขึ้นได้อย่างไรในสถานการณ์เช่นนี้? ฉันหมายถึงแม้ว่าจะมีคนขัดขวางการตอบสนองของเซิร์ฟเวอร์ (เช่น www.server.com) ด้วยคีย์สาธารณะและมีวิธีการบางอย่างที่ทำให้ฉันคิดว่าเขาเป็น www.server.com เขาก็ยังไม่สามารถถอดรหัสคีย์เซสชันของฉันได้ ไม่มีคีย์ส่วนตัว การพูดเกี่ยวกับการพิสูจน์ตัวตนซึ่งกันและกันทั้งหมดเกี่ยวกับความเชื่อมั่นของเซิร์ฟเวอร์เกี่ยวกับข้อมูลประจำตัวของไคลเอ็นต์หรือไม่? ฉันหมายความว่าลูกค้ามั่นใจได้แล้วว่าเธอกำลังสื่อสารกับเซิร์ฟเวอร์ที่ถูกต้อง แต่ตอนนี้เซิร์ฟเวอร์ต้องการค้นหาว่าลูกค้าคือใครใช่ไหม? และคำถามสุดท้ายเกี่ยวกับทางเลือกในการพิสูจน์ตัวตนร่วมกัน หากฉันทำหน้าที่เป็นไคลเอนต์ในสถานการณ์ที่อธิบายไว้ฉันจะทำอย่างไรหากฉันส่งล็อกอิน / รหัสผ่านในส่วนหัว HTTP หลังจากสร้างเซสชัน SSL อย่างที่ฉันเห็นข้อมูลนี้ไม่สามารถดักจับได้เนื่องจากการเชื่อมต่อมีความปลอดภัยแล้วและเซิร์ฟเวอร์สามารถใช้เพื่อระบุตัวตนของฉันได้ ฉันผิดเหรอ? อะไรคือข้อเสียของวิธีการดังกล่าวเมื่อเทียบกับการรับรองความถูกต้องร่วมกัน (เฉพาะปัญหาด้านความปลอดภัยเท่านั้นที่มีความสำคัญไม่ใช่ความซับซ้อนของการนำไปใช้งาน)

93 security  ssl  man-in-the-middle 

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

92 mongodb  security  meteor 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Stack Overflow ปิดให้บริการใน8 ปีที่ผ่านมา ปรับปรุงคำถามนี้ ฉันต้องการทราบว่าผู้คนพิจารณาแนวทางปฏิบัติที่ดีที่สุดในการรักษาความปลอดภัยส่วนผู้ดูแลระบบของเว็บไซต์โดยเฉพาะจากมุมมองการตรวจสอบสิทธิ์ / การเข้าถึง แน่นอนว่ามีสิ่งที่ชัดเจนเช่นการใช้ SSL และการบันทึกการเข้าถึงทั้งหมด แต่ฉันสงสัยว่าขั้นตอนพื้นฐานเหล่านี้อยู่ที่ใดที่ผู้คนพิจารณาว่าจะตั้งค่าแถบ ตัวอย่างเช่น: คุณอาศัยกลไกการตรวจสอบสิทธิ์แบบเดียวกับที่คุณใช้สำหรับผู้ใช้ทั่วไปหรือไม่? ถ้าไม่ได้อะไร? คุณเรียกใช้ส่วนผู้ดูแลระบบใน "โดเมนแอปพลิเคชัน" เดียวกันหรือไม่ คุณต้องทำขั้นตอนใดบ้างเพื่อทำให้ส่วนผู้ดูแลระบบไม่ถูกค้นพบ (หรือคุณปฏิเสธสิ่งที่ 'ปิดบัง' ทั้งหมด) จนถึงตอนนี้คำแนะนำจากผู้ตอบ ได้แก่ : แนะนำการหยุดชั่วคราวฝั่งเซิร์ฟเวอร์เทียมในการตรวจสอบรหัสผ่านของผู้ดูแลระบบแต่ละครั้งเพื่อป้องกันการโจมตีแบบดุร้าย[Developer Art] ใช้หน้าการเข้าสู่ระบบแยกกันสำหรับผู้ใช้และผู้ดูแลระบบโดยใช้ตาราง DB เดียวกัน (เพื่อหยุด XSRF และการขโมยเซสชันที่ให้สิทธิ์เข้าถึงพื้นที่ผู้ดูแลระบบ) [Thief Master] ลองเพิ่มการตรวจสอบสิทธิ์แบบเนทีฟของเว็บเซิร์ฟเวอร์ในพื้นที่ผู้ดูแลระบบด้วย (เช่นผ่าน. htaccess) [Thief Master] พิจารณาบล็อก IP ของผู้ใช้หลังจากพยายามเข้าสู่ระบบของผู้ดูแลระบบที่ล้มเหลวหลายครั้ง[Thief Master] เพิ่ม …

92 security  authentication 

ฉันกำลังพัฒนาเว็บแอปพักผ่อนที่ใช้กรอบเว็บยอดนิยมในแบ็กเอนด์พูด (ราง, ซินาตร้า, กระติกน้ำ, express.js) ตามหลักการแล้วฉันต้องการพัฒนาฝั่งไคลเอ็นต์ด้วย Backbone.js ฉันจะให้เฉพาะฝั่งไคลเอ็นต์ JavaScript ของฉันโต้ตอบกับการเรียก API เหล่านั้นได้อย่างไร ฉันไม่ต้องการให้การเรียก API เหล่านั้นเป็นสาธารณะและถูกเรียกโดยcurlหรือเพียงแค่ป้อนลิงก์บนเบราว์เซอร์

92 security  api  rest  web-applications  backbone.js 

ฉันกำลังมองหาวิธีรับตำแหน่งcacertsของการติดตั้ง java เริ่มต้นเมื่อคุณไม่มีJAVA_HOMEหรือJRE_HOMEกำหนด ฉันจำเป็นต้องใช้วิธีการแก้ปัญหาที่ทำงานอย่างน้อยสำหรับและOS XLinux ใช่. java -vถือว่าทำงาน :)

92 java  security 

ดังนั้นด้วยบริการที่แตกต่างกันมากมายในตอนนี้ Google APIs, Twitter API, Facebook API และอื่น ๆ แต่ละบริการมีคีย์ API เช่น: AIzaSyClzfrOzB818x55FASHvX4JuGQciR9lv7q คีย์ทั้งหมดมีความยาวและอักขระที่แตกต่างกันไปฉันสงสัยว่าวิธีที่ดีที่สุดในการสร้างคีย์ API คืออะไร? ฉันไม่ได้ขอภาษาใดภาษาหนึ่งเป็นเพียงวิธีการทั่วไปในการสร้างคีย์หากเป็นการเข้ารหัสรายละเอียดของแอปผู้ใช้หรือแฮชหรือแฮชของสตริงแบบสุ่ม ฯลฯ เราควรกังวลเกี่ยวกับอัลกอริทึมแฮช (MSD, SHA1, bcrypt) ฯลฯ ? แก้ไข: ฉันได้พูดคุยกับเพื่อนสองสามคน (อีเมล / ทวิตเตอร์) และพวกเขาแนะนำให้ใช้ GUID โดยมีเครื่องหมายขีดกลาง ดูเหมือนว่าจะเป็นเรื่องเล็กน้อยสำหรับฉัน แต่หวังว่าจะได้รับแนวคิดเพิ่มเติม

92 security  api-key 

สัปดาห์ที่แล้วฉันอ่านบทความมากมายเกี่ยวกับการแฮชรหัสผ่านและปักเป้าดูเหมือนว่า (หนึ่งใน) อัลกอริทึมการแฮชที่ดีที่สุดในตอนนี้ - แต่นั่นไม่ใช่หัวข้อของคำถามนี้! ขีด จำกัด 72 อักขระ ปักเป้าพิจารณาเฉพาะอักขระ 72 ตัวแรกในรหัสผ่านที่ป้อน: <?php $password = "Wow. This is a super secret and super, super long password. Let's add some special ch4r4ct3rs a#d everything is fine :)"; $hash = password_hash($password, PASSWORD_BCRYPT); var_dump($password); $input = substr($password, 0, 72); var_dump($input); var_dump(password_verify($input, $hash)); ?> …

91 php  security  hash  passwords  blowfish 

อ้างอิงจากวิกิพีเดีย: http://en.wikipedia.org/wiki/Transport_Layer_Security ดูเหมือนว่า TLS จะมาแทนที่ SSL แต่เว็บไซต์ส่วนใหญ่ยังคงใช้ SSL อยู่?

91 security  ssl 

บนไซต์ของเราเราจัดเตรียมการจำลองให้กับผู้ใช้ตามข้อมูลส่วนตัวของพวกเขา (มอบให้ผ่านแบบฟอร์ม) เราต้องการอนุญาตให้พวกเขากลับไปที่ผลการจำลองในภายหลัง แต่ไม่ต้องบังคับให้สร้างบัญชีล็อกอิน / รหัสผ่าน เราคิดว่าจะส่งอีเมลพร้อมลิงก์ให้พวกเขาเพื่อให้พวกเขาได้รับผลลัพธ์กลับมา แต่โดยปกติแล้วเราต้องรักษาความปลอดภัย URL นี้เนื่องจากข้อมูลส่วนตัวเป็นอันตราย ดังนั้นเราจึงตั้งใจที่จะส่งโทเค็น (เช่นตัวอักษรและตัวเลขผสมกัน 40 อักขระหรือแฮช MD5) ใน URL และใช้ SSL สุดท้ายพวกเขาจะได้รับอีเมลในลักษณะนี้: สวัสดีรับ ผลลัพธ์ของคุณกลับมาที่ https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn คุณคิดอย่างไรกับมัน? มีความปลอดภัยเพียงพอหรือไม่ คุณจะแนะนำอะไรฉันสำหรับการสร้างโทเค็น สิ่งที่เกี่ยวกับการส่งพารามิเตอร์ URL ในคำขอ https

91 security  url  https  token 

ฉันมีปัญหากับ--disable-web-securityธง ไม่ทำงานใน Chrome 48 และ Chrome 49 เบต้าบน Windows ฉันได้ลองฆ่าอินสแตนซ์ทั้งหมดรีบูตและเรียกใช้ Chrome ด้วยแฟล็กก่อนอื่นลองใช้เครื่องอื่นด้วย ในรุ่นเบต้าฉันเห็นป๊อปอัปคำเตือน ("คุณกำลังใช้แฟล็กที่ไม่รองรับ .. ") แต่ CORS ยังคงถูกบังคับใช้ เวอร์ชันสาธารณะดูเหมือนจะเพิกเฉยต่อการตั้งค่าสถานะโดยสิ้นเชิง ดูเหมือนจะไม่มีข่าวหรือผู้คนรายงานเกี่ยวกับเรื่องนี้ดังนั้นจึงอาจเป็นปัญหาในท้องถิ่น จะขอบคุณสำหรับความช่วยเหลือหรือข้อมูลที่เกี่ยวข้อง

91 google-chrome  security  same-origin-policy 

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

90 security  licensing  protection  software-distribution  piracy 

อัปเดต: เมื่อเร็ว ๆ นี้ฉันได้เรียนรู้จากคำถามนี้ว่าในการสนทนาทั้งหมดด้านล่างฉัน (และฉันแน่ใจว่าคนอื่น ๆ ก็ทำเช่นกัน) ค่อนข้างสับสน: สิ่งที่ฉันเรียกตารางสายรุ้งนั้นแท้จริงแล้วเรียกว่าตารางแฮช ตารางสายรุ้งเป็นสิ่งมีชีวิตที่ซับซ้อนกว่าและเป็นรูปแบบหนึ่งของ Hellman Hash Chains แม้ว่าฉันจะเชื่อว่าคำตอบนั้นยังคงเหมือนเดิม (เนื่องจากไม่ได้มีการเข้ารหัสลับ) การสนทนาบางส่วนอาจจะเบี้ยวเล็กน้อย คำถาม: " อะไรคือตารางรุ้งและวิธีการที่พวกเขาใช้? " โดยปกติฉันมักจะแนะนำให้ใช้ค่าสุ่มที่มีการเข้ารหัสที่แข็งแกร่งเป็นเกลือเสมอเพื่อใช้กับฟังก์ชันแฮช (เช่นรหัสผ่าน) เช่นเพื่อป้องกันการโจมตีของ Rainbow Table แต่จริง ๆ แล้วมันจำเป็นสำหรับการสุ่มเกลือหรือไม่? ค่าที่ไม่ซ้ำกัน (ไม่ซ้ำกันต่อผู้ใช้เช่น userId) จะเพียงพอหรือไม่ในเรื่องนี้ ในความเป็นจริงมันจะป้องกันไม่ให้ใช้ Rainbow Table เดียวเพื่อถอดรหัสรหัสผ่านทั้งหมด (หรือส่วนใหญ่) ในระบบ ... แต่การขาดเอนโทรปีทำให้ความแข็งแกร่งในการเข้ารหัสของฟังก์ชันแฮชลดลงหรือไม่? หมายเหตุฉันไม่ได้ถามว่าทำไมต้องใช้เกลือวิธีการป้องกัน (ไม่จำเป็นต้องเป็น) การใช้แฮชคงที่เดียว (ไม่ต้อง) หรือฟังก์ชันแฮชประเภทใดที่จะใช้ เพียงแค่ว่าเกลือต้องการเอนโทรปีหรือไม่ ขอบคุณทุกคนสำหรับคำตอบจนถึงตอนนี้ แต่ฉันอยากจะเน้นในส่วนที่ฉันไม่ค่อยคุ้นเคย (นิดหน่อย) ผลกระทบส่วนใหญ่สำหรับการเข้ารหัส …

89 security  authentication  hash  cryptography  password-protection