گذرواژهها – هنگام اجرای اسکریپتهای پوسته، انتقال اطلاعات حساس از طریق stdin یا به عنوان یک گزینه رشته امن تر است؟

من تعدادی از اسکریپت های اتوماتیک را اجرا می کنم که در یک محیط رمزگذاری شده (رمزگذاری کامل دیسک) اجرا می شوند.

بسیاری از دستورات در ویندوز و nix دو راه برای ورود اطلاعات حساس مانند کلمات عبور دارند. در یک حالت، برنامه کاربر را برای گذرواژه فراخوانی می کند و از سوی دیگر، رمز عبور با استفاده از یک آرگومان گزینه مشخص می شود.

هنگام نوشتن یک اسکریپت پوسته، فرمان می تواند به صورت خودکار با استفاده از هر یک از این فرآیندها خودکار شود. در اولین مورد، فرمان اجرا می شود، سپس استاندارد در (stdin) هدایت می شود و پسورد در صورت درخواست، رمز عبور وارد برنامه می شود. در مورد دوم، رمز عبور به عنوان یک استدلال به برنامه مشخص شده است.

آیا یکی از این موارد ذاتا بیشتر از دیگران خطرناک است؟ آیا آگاهی از مواردی وجود دارد؟ در هر دو مورد، من به طور خاص درباره نحوه تأمین گذرواژه، و نه احتمال خطر یا آسیب پذیری مرتبط با ذخیره رمز عبور روی دیسک، از شما خواهم پرسید.

در مثال زیر در Python با استفاده از نسخه CLI از VeraCrypt:

هدایت stdin:

 cmd = ['veracrypt', "--text", partition, mount_point]
input_file = open_file ()
vc_call = subprocess.run (cmd، stdin = input_file)
vc_call.wait ()

عبور گذرواژه به عنوان یک استدلال:

 password = get_password_from_file ():
cmd = ['veracrypt', "--text", "--non-interactive", "--password", password, partition, mount_point]
vc_call = subprocess.run (cmd)

توجه:

من مطمئن نیستم که اگر مهم باشد، اما در * nix، دستورات می توانند به طور مستقیم به عنوان فراخوانی های سیستم اجرا شوند. در کد بالا هیچکدام از تماسهای زیر subprocess.run () یک گزینه shell = True داده نشد، که باعث می شود دستور در پوسته پیشفرضی اجرا شود. درک من این است که در ویندوز تمام دستورات باید از طریق shell cmd اجرا شود. این می تواند بین دو گزینه تفاوت ایجاد کند، اما من مطمئن نیستم که چگونه

احراز هویت – آیا می توانم کلید خصوصی را دور بریزم و از کلید عمومی مانند یک تابع هش استفاده کنم؟

بله بله من می دانم "پروتکل های خود را منفجر کنید مگر اینکه متخصص باشید". لازم نیست که به من دروغ بگید فقط می خواهم بدانم که آیا این ایده نقص وجود دارد و اگر کسی چنین کاری را قبلا انجام نداده است

انگیزه این است که می خواهم توانایی تأیید هویت کاربران را داشته باشم. من می دانم که راه حل استاندارد این است که کلمه عبور هلو را بخورند. اما من این واقعیت را دوست ندارد که رمز عبور خود را به سرور ارسال کند تا آن را بررسی کند. چه کسی در مورد گوش دادن طرف سرویس گیرنده می تواند رمز عبور را رمزگذاری و ارسال کند، اما من آن را دوست ندارم، زیرا ممکن است نکته کلید رمزگشایی من و کسی که ترافیک وب قبلی را ثبت کرده است بتواند تمامی رمزهای عبور را محاسبه کند. تأیید اعتبار یک مشکل جدید نیست، بنابراین من بیشتر در مورد جوانب مثبت و منفی راه حل های معمول قرار نمی گیرم.

ایده من

برای هر کاربر (a) سرور یک کلید عمومی (g ^ x_a) و رمز عبور رمزگذاری شده با آن کلید عمومی (g ^ {x_a} * p_a) را ذخیره می کند. کلید خصوصی مربوطه یا فورا از بین رفت و یا (هنوز بهتر) هرگز محاسبه نشده است. فرآیند احراز هویت به شرح زیر است:

  1. کاربر آلیس می خواهد برای تأیید اعتبار

  2. سرور باب یک کلید عمومی موقت عمومی G ^ t (دوباره بدون یک کلید خصوصی مرتبط) تولید می کند. باب این کلید موقت عمومی را در داده های آلیس خود افزایش می دهد. در نتیجه g ^ t * g ^ {x_a} = g ^ {t + x_a} = g ^ {x_a} 'و g ^ t * g ^ {x_a} * p_a = g ^ {t + x_a} * p_a = g ^ {x_a} '* p_a. باب از کلید عمومی موقت دور می شود و تنها با یک کلید عمومی جدید (g ^ {x_a} ') و رمز عبور آلیس رمزگذاری شده با این کلید است. او کلید جدیدی برای آلیس می فرستد.

  3. آلیس کلید دریافت شده توسط باب از آن برای رمزگذاری رمز عبور خود استفاده می کند. او مقدار رمزگذاری شده را به باب می فرستد.

  4. باب آلیس را تصدیق می کند اگر مقدار داده شده مطابقت با آنچه که در ضبط داشته است باشد.

برای recap

  1. هیچ وقت سرور یا یک هکر پایگاه داده رمزگشایی نمی کند. با کلید های خصوصی ردیابی رمزنگاری کلید عمومی به طور موثری مانند هش کار می کند.

  2. از آنجا که هر کاربر با یک کلید متفاوت رمزگذاری شده است، کلمه عبور به طور مؤثری گرم می شود. جدول رنگین کمان اینجا کار نمی کند

  3. یک هکر با تصویر قبلی از پایگاه داده می تواند ارزش های آینده g ^ x_a * p_a را با گوش دادن به ترافیک وب به دست نمی آورد، زیرا این امر نیاز به کشف کلید موقت دارد (که نیازمند حل مجله گسسته است). بنابراین یک تصویر پایگاه داده نشتی اجازه نمیدهد که مهاجم خود را مجبور به جعل هویت کاربران کند.

  4. هیچ سرور یا مشتری هیچ کلید خصوصی برای مدیریت ندارد. فقط مشتری نیاز به نگه داشتن اطلاعات مخفی و اطلاعات مخفی را می توان انسان قابل خواندن است.

  5. (معایب) مهاجم یک پنجره کوچک از زمان بین مراحل 2 و 4 دارد که می تواند به سرور نفوذ کند و با استفاده از داده هایی که پیدا کرده است، یک کاربر را جعل هویت کند.

گذرواژهها – آیا عبارتی از کلمه کلیدی صحبت می کند؟

(ما فقط باید یک دکمه برای پیوند این XKCD داشته باشیم)

من تازه شروع به تغییر گذرواژههایم کردم. حالا، من هر گونه تاس را رها نکردم تا آنها را بیاورم، که من آنتروپی را فدا می دانم؛ آنها جملات هستند آنها حداقل 25 کاراکتر طول می کشد، حداقل 5 کلمه، و من سعی می کنم یک عدد در آن وجود داشته باشد و همچنین یک کلمه "جعلی" (این می تواند یک کلمه ای است که من مرتب می کنم یا یک کلمه غیر استاندارد مانند "doggo" یا "borked").

اکنون، می دانم که من یک ساختار دارم، به این معنی که من آنتروپی بالقوه را از دست داده ام، اما پیامی که از XKCD دور کردم، این است که memorizablity منبعی است که حداکثر آنتروپی را به حداکثر می رساند. من قدردانی می کنم که می توانم به این همسایه ها این رمز ها را بدون نیاز به هرگز آنها بنویسند (یا، الزام الهی، متن / ایمیل آنها را). من امیدوارم هرگز یک رمز عبور فعال را مشاهده نکنم.

سوال من بعد این است که برای اضافه کردن یک عنصر "Tr0ub4dor" به عبارت عبور من اضافه شود؟

شما می توانید فرض کنید هر تغییری به راحتی حفظ می شود من اغلب کنجکاو هستم اگر یک عبارت عبور به اندازه کافی آنتروپی را به خود اختصاص دهد که راهکارهای سنتی برای آنتروپی دیگر مرتبط نیستند. به عنوان مثال، آیا رمز دوم دوم در اینجا عملی است یا بهتر از اول؟

mydoggoShrekate7bonesyesterday
myd0ggoShr3k4te7bon3 $ yesterd @ y

(همچنین لطفا فقط پیشنهاد مدیر رمز عبور. دلایل من برای تمایل به اجتناب از یکی.)

آیا محدودیتی در زمان وجود دارد که یک گذرواژه بر اساس شتاب ورود پذیری قابل قبول و نسبت سرعت سختافزاری به نیروی بی رحم دارد؟

فرض کنید کاربر یک رمز عبور برای ورود به کامپیوتر خود استفاده می کند. هنگامی که کاربر وارد سیستم می شود، کامپیوتر یک تابع رمزنگاری را به رمز عبور می دهد و متن رمز را به متن رمز ذخیره شده رمز عبور شناخته می کند (این تابع رمزنگاری می تواند "سخت" باشد تا حملات خشونت آمیز مشکل باشد). مهاجم دسترسی فیزیکی به دستگاه را به دست آورد، از جمله رمز عبور رمز عبور ذخیره شده – به این ترتیب آنها دسترسی به تمام فایل های رمزگذاری نشده در دستگاه خود دارند، اما مهاجم می خواهد رمز عبور را نیز دریافت کند (شاید بدانید رمز عبور کاربر به آنها کمک خواهد کرد حدس زدن رمز عبور کاربر در سرویس های دیگر، در میان چیزهای دیگر).

به نظر می رسد که یک قضیه وجود دارد که حد بالا را برای مدت زمانی که مهاجم می تواند به زور به رمز عبور کاربر تحمیل کند تاخیر دهد. اگر N تعداد رمزهای عبور در فضای پیچیدگی است که یک کاربر واقعی احتمال دارد از آن انتخاب شود، و t حداکثر زمانی است که کاربر مایل است تا عمل رمزنگاری را به گذرواژه ورود به هش خود منتظر بگذارد، R نسبت سرعت سخت افزار مهاجم به سرعت سخت افزار کاربر، و سپس حداکثر زمان برای مهاجم برای خلع سلاح رمز عبور کاربر N * t / R

به عنوان مثال، اگر 10 میلیون رمز عبور با پیچیدگی وجود دارد از رمز عبور که کاربر احتمالا از آن انتخاب کند، و کاربر مایل است پس از تایپ کردن رمز عبور خود، 3 ثانیه صبر کند و سخت افزار حمله کننده 100 برابر سریعتر از سخت افزار کاربر باشد، و حداکثر زمان برای مهاجم به رمزعبور بی پروا 10،000،000 * (3 ثانیه) / 100 = حدود 3.5 روز است.

متاسفانه، این به نظر می رسد که حد بالا است که مستقل از چه سخت افزار و چه عملکرد رمزنگاری شما استفاده می کنید. همواره محدودیتی در مورد اینکه چگونه افراد پیچیده گذرواژه خود را ایجاد می کنند وجود دارد، محدودیتی در میزان طولانی از تأخیر زمانی که کاربران هنگام ورود به سیستم تحمل می کنند محدود می شود و یک مهاجم به خوبی تامین مالی می تواند همیشه سخت افزار را دریافت کند بار سریعتر از آنچه که کاربر معمولی از آن استفاده می کند (اگر فقط با خرید 100 لپ تاپ یکسان است با لپ تاپ کاربر).

بنابراین، دو چیز:

  1. آیا منطق در اینجا صدا؟
  2. آیا این یک قضیه شناخته شده است چه کسی دیگر به مدت طولانی اشاره کرده است و از قبل نام دارد؟
  3. برخی از چیزهایی که می توان برای مقابله با این مسئله انجام داد، چیست؟

گذرواژه – پیوند سرور ایمیل با پایگاه داده برنامه

من یک برنامه وب در node.js دارم که توسط یک پایگاه داده MongoDB که داده های کاربر را ذخیره می کند، پشتیبانی می کند. من می خواهم کاربران خود را یک حساب ایمیل بگذارم، بنابراین یک سرور ایمیل با استفاده از Postfix تنظیم کردم ، dovecot، و غیره … مشکل من این است که من می خواهم دو پایگاه داده کاربر را پیوند دهم. در حال حاضر من postfix و dovecot پیکربندی شده برای استفاده از کاربران مجازی ذخیره شده در پایگاه داده MySQL (واقعا MariaDB)، و این کار خوب است (من می توانم دسترسی و ارسال ایمیل بر روی IMAP و غیره …). با این حال، من می خواهم که کاربران خود بتوانند از همان رمز عبور برای IMAP برای ورود به برنامه وب استفاده کنند. من خوشحالم که یک API PHP را برای ایجاد کاربران در سرور پست الکترونیکی و غیره بنویسید، اما مسئله من این است که چگونه رمز عبور را مدیریت کنید. همانطور که می بینم، دو گزینه وجود دارد؛

  1. من می توانم کلمه عبور متن ساده را از سرور برنامه های وب خود به سرور پست الکترونیکی خود منتقل کنم زمانی که یک کاربر ثبت نام یا تغییر رمز عبور. پس از آن، به طور واضح در سرور پست الکترونیکی هشدار داده می شود و در پایگاه داده ذخیره می شود و در سرور درخواست شده ذخیره می شود و در پایگاه داده MongoDB ذخیره می شود. این باعث می شود که من اشتباه کنم – رمز عبور متن ساده را با دو بار تکرار رمز عبور ارسال کنم
  2. من می توانم رمزهای عبور هشدار را از سرور برنامه به سرور ایمیل انتقال دهم و آنها را دوباره ذخیره کنم بدون . باز هم، این احساس بسیار خجالتی است، از دیدگاه سرور ایمیل، گذرنامه ها را می پذیرد و آنها را در متن واضح ذخیره می کنند.

آیا گزینه های دیگری برای اجازه دادن به کاربران من برای ورود به هر دو سرور با همان اعتبار وجود دارد؟ چه مسائل امنیتی با دو گزینه ای که از بالا مطرح کردم وجود دارد؟