ব্যবহারকারী পাসওয়ার্ড পরিষ্কার করা

Question

ব্যবহারকারীর দ্বারা সরবরাহিত পাসওয়ার্ডগুলি হ্যাশ করে আমার ডেটাবেসে সংরক্ষণ করার আগে কীভাবে আমার পালানো বা পরিষ্কার করা উচিত?

যখন পিএইচপি বিকাশকারীরা সুরক্ষার উদ্দেশ্যে ব্যবহারকারীদের পাসওয়ার্ডগুলি হ্যাশ করার বিষয়টি বিবেচনা করে, তারা প্রায়শই এই পাসওয়ার্ডগুলি নিয়ে ভাবেন যেমন তারা অন্য কোনও ব্যবহারকারীর সরবরাহিত ডেটা করবে। এই বিষয়টি প্রায়শই পাসওয়ার্ড স্টোরেজ সম্পর্কিত পিএইচপি প্রশ্নের মধ্যে আসে; ডেভেলপার প্রায়ই যেমন ফাংশন ব্যবহার করে পাসওয়ার্ড ধোয়া করতে চায় escape_string()(বিভিন্ন পুনরাবৃত্তিও মধ্যে), htmlspecialchars(), addslashes()এবং এটি হ্যাশ এবং ডাটাবেস মধ্যে এটি সংরক্ষণ করার আগে অন্যদের।

Comments

আপনি বেসড 64 এনকোড ব্যবহার করতে পারেন

— এমএসএস

@ এমএসএস নয়, আপনার উচিত নয় কারণ বেস 64 এনকোডিং করছে , এনক্রিপ্ট বা হ্যাশিং নয় । পাসওয়ার্ড সর্বদা হ্যাশ করা উচিত ।

— জে ব্লানচার্ড

আমি হ্যাশ এর আগে বোঝাতে চাইছি;)

— এমএসএস

হ্যাশিংয়ের আগে আপনার এটি করা উচিত নয় এবং করা উচিত নয়। এটি আপনাকে এমএমএসে অপ্রয়োজনীয় অতিরিক্ত কোড লিখতে বাধ্য করবে

— জে

Answer 1

আপনি পিএইচপি-র সাথে হ্যাশ করে যাবেন এমন পাসওয়ার্ডগুলিতে আপনাকে কখনই পালানো, ছাঁটাই বা অন্য কোনও পরিষ্কারকরণ ব্যবস্থা ব্যবহার করা উচিত নয় password_hash() , এর মধ্যে সবচেয়ে বড়টি কারণ পাসওয়ার্ডে অতিরিক্ত পরিস্কার করার জন্য অপ্রয়োজনীয় অতিরিক্ত কোডের প্রয়োজন হয় requires

আপনি তর্ক করবেন (এবং আপনি এটি প্রতিটি পোস্টে দেখতে পাবেন যেখানে ব্যবহারকারীর ডেটাগুলি আপনার সিস্টেমে ব্যবহারের জন্য গৃহীত হয়) যে আমাদের সমস্ত ব্যবহারকারীর ইনপুট পরিষ্কার করা উচিত এবং আমরা আমাদের ব্যবহারকারীদের কাছ থেকে গ্রহণযোগ্য প্রতিটি তথ্যের জন্যই সঠিক হতে পারি। পাসওয়ার্ডগুলি আলাদা। হ্যাশ করা পাসওয়ার্ডগুলি কোনও এসকিউএল ইঞ্জেকশন হুমকির প্রস্তাব দিতে পারে না কারণ ডাটাবেসে সংরক্ষণের আগে স্ট্রিংটি হ্যাশে পরিণত হয়।

পাসওয়ার্ড হ্যাশ করার কাজটি আপনার ডেটাবেজে পাসওয়ার্ডটি নিরাপদে রাখার কাজ। হ্যাশ ফাংশনটি কোনও বাইটকে বিশেষ অর্থ দেয় না, সুতরাং সুরক্ষা কারণে কোনও কারণে এর ইনপুট পরিষ্কারের প্রয়োজন হয় না

আপনি যদি ব্যবহারকারীদের তাদের পছন্দসই পাসওয়ার্ড / বাক্যাংশ ব্যবহার করার অনুমতি দেওয়ার মন্ত্রগুলি অনুসরণ করেন এবং আপনি পাসওয়ার্ড সীমাবদ্ধ না করেন , কোনও দৈর্ঘ্য, কোনও স্থানের সংখ্যা এবং কোনও বিশেষ অক্ষরের হ্যাশিং এর মধ্যে যা কিছু থাকে তা পাসওয়ার্ড / পাসফ্রেজকে নিরাপদ করে দেবে শব্দসংকেত. এই মুহূর্তে সর্বাধিক সাধারণ হ্যাশ (ডিফল্ট), PASSWORD_BCRYPTপাসওয়ার্ডটিকে হ্যাশ পাসওয়ার্ডের তথ্য এবং একটি ব্যয় (হ্যাশ তৈরির আলগোরিদিমিক ব্যয়) সহ একটি এলোমেলো লবণযুক্ত একটি 60 অক্ষরের প্রশস্ত স্ট্রিংয়ে রূপান্তরিত করে:

PASSWORD_BCRYPT CRYPT_BLOWFISH অ্যালগরিদম ব্যবহার করে নতুন পাসওয়ার্ড হ্যাশ তৈরি করতে ব্যবহৃত হয়। এটি সর্বদা "$ 2y $" ক্রিপ্ট ফর্ম্যাট ব্যবহার করে একটি হ্যাশের ফলস্বরূপ, যা সর্বদা 60 অক্ষর প্রস্থ।

হ্যাশ সংরক্ষণের জন্য স্থানের প্রয়োজনীয়তাগুলি পরিবর্তিত হতে পারে কারণ ফাংশনে বিভিন্ন হ্যাশিং পদ্ধতি যুক্ত করা হয়, তাই সঞ্চিত হ্যাশগুলির জন্য কলামের ধরণে আরও বড় হওয়া ভাল VARCHAR(255)orTEXT ।

আপনি আপনার পাসওয়ার্ড হিসাবে একটি সম্পূর্ণ এসকিউএল ক্যোয়ারী ব্যবহার করতে পারেন এবং এটি হ্যাশ হয়ে যাবে, এসকিউএল ইঞ্জিন দ্বারা এটি অনিবার্য করে তোলে যেমন,

SELECT * FROM `users`;

তাড়াতাড়ি করা যেতে পারে $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G

আসুন দেখুন কীভাবে বিভিন্ন স্বাস্থ্যবিধি পদ্ধতি পাসওয়ার্ডকে প্রভাবিত করে -

পাসওয়ার্ডটি হ'ল I'm a "dessert topping" & a <floor wax>! (এখানে শেষে 5 টি স্পেস রয়েছে যা এখানে প্রদর্শিত হয় না))

আমরা যখন ছাঁটাইয়ের নিম্নলিখিত পদ্ধতিগুলি প্রয়োগ করি তখন আমরা কিছু বুনো বিভিন্ন ফলাফল পাই:

var_dump(trim($_POST['upassword']));
var_dump(htmlentities($_POST['upassword']));
var_dump(htmlspecialchars($_POST['upassword']));
var_dump(addslashes($_POST['upassword']));
var_dump(strip_tags($_POST['upassword']));

ফলাফল:

string(40) "I'm a "dessert topping" & a <floor wax>!" // spaces at the end are missing
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // double quotes, ampersand and braces have been changed
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // same here
string(48) "I\'m a \"dessert topping\" & a <floor wax>!     " // escape characters have been added
string(34) "I'm a "dessert topping" & a !     " // looks like we have something missing

আমরা এগুলিতে পাঠালে কী হয় password_hash()? উপরে উঠে থাকা কোয়েরি যেমন হয়েছে তেমনি এগুলি সমস্ত হ্যাশ হয়ে যায়। আপনি পাসওয়ার্ড যাচাই করার চেষ্টা করার সময় সমস্যাটি আসে। আমরা যদি এই পদ্ধতিগুলির এক বা একাধিক নিয়োগ করি তবে তাদের সাথে তুলনা করার আগে আমাদের অবশ্যই তাদের পুনরায় নিয়োগ করতে হবে password_verify()। নিম্নলিখিত ব্যর্থ হবে:

password_verify($_POST['upassword'], $hashed_password); // where $hashed_password comes from a database query

পাসওয়ার্ড যাচাইকরণের ফলাফলটি ব্যবহারের আগে আপনাকে যে ক্লিনিজিং পদ্ধতিটি বেছে নিয়েছিল তার মাধ্যমে পোস্ট করা পাসওয়ার্ডটি চালাতে হবে। এটি পদক্ষেপের একটি অপ্রয়োজনীয় সেট এবং হ্যাশকে আরও ভাল করে তুলবে।

---

পিএইচপি সংস্করণ 5.5 এর চেয়ে কম ব্যবহার করছেন? আপনি password_hash() সামঞ্জস্যতা প্যাক ব্যবহার করতে পারেন ।

আপনার সত্যিই MD5 পাসওয়ার্ড হ্যাশ ব্যবহার করা উচিত নয় ।

Comments

না, যদি তিনি পাসওয়ার্ডটি ফাঁকা ফাঁকা স্থানগুলির সাথে তৈরি করেন, যা অনুমোদিত, তবে অবশ্যই সেগুলি লগইন করতে হবে @ ডানব্রাকুক

— জে

কিভাবে ড্যানব্রাকুক? আমরা যদি ব্যবহারকারীকে অগ্রণী / অনুসরণের স্থানগুলি সহ পাসওয়ার্ড সেটআপ করার অনুমতি দিই?

— জে ব্লানচার্ড

এজন্য বেশিরভাগ জিনিসের জন্য আপনার চয়ন করা পাসওয়ার্ড দুবার প্রবেশ করা প্রয়োজন। যদি ব্যবহারকারী দুর্ঘটনায় শূণ্যস্থান যোগ করে থাকে তবে তারা আরও কিছু পাওয়ার আগে এটি সনাক্ত করবে। ব্যবহারকারী যদি উদ্দেশ্যহীনভাবে এটি ইস্যু না করে করে থাকে।

— আমি একবার ভাল্লুক কুস্তি করেছিলাম।

@ মার্গারেটলুম, থাম্বের একটি বিধি কেবল একটি হিউরিস্টিক। আমাদের মাঝে মাঝে পাসওয়ার্ডের মতো জিনিসগুলির মাধ্যমে এখনও চিন্তা করা প্রয়োজন। আপনি বলেছিলেন যে "ভবিষ্যতে পরিস্থিতি কীভাবে বদলে যাবে তা কেউ জানে না", তবে মনে হয় ডাটাবেজে রাখার আগে আমাদের যেভাবে তথ্য পালাতে হবে সেভাবেই যদি কোনও কিছু পরিবর্তন হয়ে যায় তবে এই ক্ষেত্রে ব্যবহারকারীরা তাদের পাসওয়ার্ড নং না থাকাকালীন নিজেকে লকড খুঁজে পাবেন would আর আমরা কী সংরক্ষণ করেছি তা মেলে। পাসওয়ার্ড হ্যাশগুলি পালাতে না পেরে বিপদ কী? বনাম সেগুলি থেকে পালানোর বিপদটি কী?

— ডেভিডএস

ঠিক: আপনি অবশ্যই প্যারামিটারাইজড এসকিউএল কোয়েরিতে সঠিকভাবে পাস করার সীমিত অর্থে "হ্যাশ থেকে বাঁচবেন", যেখানে আপনার এসকিউএল সংযোগকারীটির কিছু কোড "পলায়ন" এর সাথে মিলে এমন কিছু করতে বা করতে পারে না, আপনি ডান ' জানা নেই এবং যত্ন নেই। এটি অর্জনের জন্য আপনাকে কেবল কোনও নির্দিষ্ট কোড লিখতে হবে না, কারণ আপনি যদি ইতিপূর্বে কিছু দুর্বল জীবনের সিদ্ধান্ত না নেন তবে এটি আপনার সমস্ত এসকিউএল প্রশ্নের জন্য সম্পূর্ণ নিয়মিত।

— স্টিভ জেসোপ

Answer 2

পাসওয়ার্ডটি হ্যাশ করার আগে, আপনার এটি আরএফসি 7613 এর বিভাগ 4 হিসাবে বর্ণিত হিসাবে স্বাভাবিক করা উচিত । নির্দিষ্টভাবে:

2. অতিরিক্ত ম্যাপিংয়ের নিয়ম: অ-এসসিআইআই স্পেসের কোনও উদাহরণ অবশ্যই ASCII স্পেসে (ইউ + 0020) ম্যাপ করা উচিত; একটি নন-এএসসিআইআই স্পেস এমন কোনও ইউনিকোড কোড পয়েন্ট যা "জেডস" এর ইউনিকোডের সাধারণ বিভাগের (ইউ + 0020 বাদে) রয়েছে।

এবং:

4. নরমালাইজেশন বিধি: ইউনিকোড নরমালাইজেশন ফর্ম সি (এনএফসি) অবশ্যই সমস্ত অক্ষরের জন্য প্রয়োগ করা উচিত।

এটি নিশ্চিত করার চেষ্টা করে যে ব্যবহারকারী যদি একই পাসওয়ার্ড টাইপ করে তবে একটি ভিন্ন ইনপুট পদ্ধতি ব্যবহার করে তবে পাসওয়ার্ডটি এখনও স্বীকার করা উচিত।

Comments

@ ডেভিডস, একটি দুর্দান্ত চকচকে উত্তর আমেরিকান ম্যাক বুক (যা যাওয়ার আগে জো ব্যবহার করেছিলেন) এবং একটি দুর্বল আন্তর্জাতিকাইজড তাইওয়ানিজ ইন্টারনেট ক্যাফে কম্পিউটার (যে ডাউনলোড ডাউনলোডের জন্য জো ব্যবহারের চেষ্টা করছেন তা হ'ল ফ্লাইট ব্যাক বোর্ডিং কার্ড)।

— মার্গারেট ব্লুম

জিংগোস্টিক লাগছে। :-) ধন্যবাদ যদিও.

— ডেভিডএস

হুঁ। আপনি যদি এটি করেন তবে তা-সাইন-আপ না করে থাকা অক্ষরগুলিকে বাতিল করতে আপনাকে পাসওয়ার্ডও বৈধ করে তুলতে হবে। এটি ভয়াবহ হবে যদি কোনও ব্যবহারকারী নিউফ্যাংল্যাড স্পেস ব্যবহার করে, যা আপনার অ্যাপ্লিকেশনটি স্বীকৃতি দেয় না এবং তাই হ'ল হ্যাশ করে, এবং তারপরে আপনি আপনার ইউনিকোড চরিত্রের ডেটাবেস আপগ্রেড করেন এবং হঠাৎ হ্যাশিংয়ের আগে NEWFANGLED স্পেসটি স্পেসে ম্যাপ করা হয়, যেমন সে (গুলি) আপনার অ্যাপ্লিকেশনটি পুরানো হ্যাশটিতে এমন কোনও পাসওয়ার্ড প্রবেশ করতে পারে না।

— রুখ 22

@ জায়েব্ল্যানচার্ড কারণ আপনি যখন একটি মেশিনে একটি স্পেস বার টিপুন এবং অন্য মেশিনে চাপলে আপনি দুটি ভিন্ন ইউনিকোড কোড পয়েন্ট পেতে পারেন এবং তাদের দুটি পৃথক ইউটিএফ -8 এনকোডিং থাকতে পারে, ব্যবহারকারী কোনও কিছু সম্পর্কে অবগত না হয়ে। এটি যুক্তিযুক্ত হতে পারে যে এটি এমন একটি সমস্যা যা আপনি উপেক্ষা করতে চান, তবে আরএফসি 7613 এর বাস্তব জীবনের সমস্যাগুলি বহন করেছে, এটি কোনও কাজের প্রস্তাব নয়।

— আনস্ল্যান্ডার মনিকা 27'16

@রুখ একবার আপনি কোনও নির্দিষ্ট উপায়ে পাসওয়ার্ডগুলি হ্যান্ডেল করার সিদ্ধান্ত নেওয়ার পরে সেগুলি অবশ্যই সেভাবে পরিচালনা করা হবে, অন্যথায় বিদ্যমান ব্যবহারের ক্ষেত্রে জিনিসগুলি ভেঙে যাবে। আপনি যদি ভবিষ্যতে প্রিপ্রোসেসিং পদ্ধতি পরিবর্তন করতে চান, আপনার পাসওয়ার্ডের প্রিপ্রোসেসড এবং হ্যাশ প্রতিনিধিত্বের পাশাপাশি এটি সংরক্ষণ করা উচিত। এইভাবে, একবার আপনি ইনপুটটি গ্রহণ করার পরে, আপনি কী তুলনা করছেন তার উপর ভিত্তি করে আপনি প্রিপ্রোসেসিং / হ্যাশিং পদ্ধতি নির্বাচন করেন।

— আনস্ল্যান্ডার মনিকা 27'16