20

আমি যদি এমন কোনও অ্যাপের জন্য লগইন তৈরি করি যার মাঝারি থেকে কম সুরক্ষা ঝুঁকি রয়েছে (অন্য কথায়, এটি কোনও ব্যাংকিং অ্যাপ বা কোনও কিছু নয়) তবে কেবলমাত্র এমন কিছু বলে ব্যবহারকারীর দ্বারা প্রবেশ করা পাসওয়ার্ড যাচাই করা কি আমার পক্ষে গ্রহণযোগ্য?

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

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

আপডেট: নির্দিষ্ট প্রকল্পটি একটি ওয়েব পরিষেবা হিসাবে দেখা যায়, যাচাইকরণটি পুরোপুরি সার্ভারের পক্ষে থাকে এবং এটি উন্মুক্ত উত্স নয়। আপনি কীভাবে এর সাথে ডিল করবেন তা ডোমেন পরিবর্তন করে?

security passwords validation

— মরগান হের্লোকার
সূত্র

3

এটি নির্ভর করে কোথা থেকে বৈধপ্যাসওয়ার্ড আসে? যদি এটি হার্ডকোডযুক্ত থাকে তবে আপনি কোডটি পরিবর্তন না করেই পাসওয়ার্ড কনফিগার / পরিবর্তন করতে পারবেন না। যদি এটি কোনও কনফিগারেশন ফাইল থেকে আসে তবে যে কেউ এটি অ্যাক্সেস করে তার কাছে এটি দৃশ্যমান।

— আলব

1

"ব্যবহারকারীর নাম / পাসওয়ার্ড কম্বোতে যথেষ্ট পরীক্ষা" কি করতে হবে?

— ক্রিস

3

@ পপিওনিয়ন: এটি লগইন না করাই অসম্ভব বলে মনে হচ্ছে। এই জাতীয় দৃ strong় দাবির জন্য দয়া করে কিছু যুক্তি সরবরাহ করুন।

— মরগান হের্লোকার

1

আপনার পরিভাষাটি ভুল, যখন আপনি কোনও পাসওয়ার্ডের সাথে এটির যাচাইয়ের বিষয়টি তুলনা করছেন তা নিশ্চিত করছেন না। পার্থক্যটি বুঝতে সময় নিন take

— বিলি.বব

1

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

— রেন হেনরিচস

26

এসএসএল ছাড়া না

সরল পাঠ্যে পাসওয়ার্ড যদি নেটওয়ার্কের কাছে পাঠানো হয় তবে এটি নিরাপদ নয়। সরল পাঠ্যে পাসওয়ার্ডটি যদি নেটওয়ার্কে প্রেরণ করা হয় তবে সার্ভারের পাশ দিয়ে পাসওয়ার্ড হ্যাশ করাও নিরাপদ নয়।

যেহেতু এইচটিএমএল <input type="password"/>ট্যাগ এর বিষয়বস্তু সরল পাঠ্যে প্রেরণ করে, তাই আপনি সার্ভারে পাসওয়ার্ড কীভাবে সংরক্ষণ করবেন তা বিবেচনা করা আপনার সমস্যা নয়, যদি না আপনার ওয়েবসাইটটি পাসওয়ার্ড প্রেরণ করতে এসএসএল ব্যবহার করে না।

(এইচটিটিপি প্রমাণীকরণ, যা একটি পাসওয়ার্ড চেয়ে ব্রাউজারে একটি ডায়ালগ বাক্স পপ আপ করে, সার্ভার এবং ব্রাউজারে কোন প্রমাণীকরণ পদ্ধতিতে সাধারণ বিষয় রয়েছে তার উপর নির্ভর করে স্পষ্ট পাঠ্য বা নাও থাকতে পারে So সুতরাং এটি ব্যবহার না করে এড়াতে পারা উপায় a SSL এর।)

সাইট প্রশাসকরা সন্দেহ হলে নয়

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

প্রশাসকের কাছ থেকে পাসওয়ার্ডগুলি সুরক্ষিত রাখার একটি উপায়

পাসওয়ার্ডগুলি সংরক্ষণ এবং চেক করার একটি নিরাপদ উপায় নিম্নরূপ:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

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

আপনার পরিবেশের উপর নির্ভর করে, আপনার নেটওয়ার্কের প্রচ্ছন্নতার পরিবর্তনশীলতা এবং ব্যবহারকারীর নামগুলি সর্বজনবিদিতভাবে পরিচিত কিনা তা বোঝা যাচ্ছে, hash('0000'+entered_password)আক্রমণকারীদের হাত থেকে রোধ করার জন্য ব্যবহারকারীর উপস্থিতি না থাকলে আপনি অন্য একটি কোড পাথের গণনা করতে চাইতে পারেন কোন ব্যবহারকারীর নাম বৈধ কিনা তা নির্ধারণের সময় নিরীক্ষণ করে যে পাসওয়ার্ডটি ভুল।

— কেন ব্লুম
সূত্র

1

গুড উপদেশাবলী :) SSL এর ব্যাপারে, আমরা এমন কিছু বিষয় যা কাজ করবে ডিজাইন করতে হতো বন্য মধ্যে এবং নিছক পাসওয়ার্ড (জাভাস্ক্রিপ্ট প্রয়োজন) এনকোড এবং তারপর সার্ভারে এটা ডিকোড করতে asymetric ক্রিপ্টোগ্রাফি ব্যবহার করেছিলেন। লবণ + হ্যাশ এর পরে সাধারণত দেখা যায়। এছাড়াও, যেহেতু সর্বজনীন কী ওয়েব-পৃষ্ঠার সাথে প্রেরণ করা হয়, তাই এটি প্রায়শই প্রায়শই পরিবর্তন হতে পারে।

— ম্যাথিউ এম।

1

@ ম্যাথিউ এম: যখন কেউ আপনার ওয়েবপৃষ্ঠাটি নকল করতে পারে, তিনি সেখানকার পাবলিক কীটি এমন একটিতে পরিবর্তন করতে পারেন যেখানে তিনি নিজেই সম্পর্কিত ব্যক্তিগত কীটি জানেন। সুতরাং আপনার ধারণাটি কেবল প্যাসিভ পঠন-আক্রমণগুলির বিরুদ্ধে সহায়তা করে, মধ্য-মধ্যবর্তী লোকদের বিরুদ্ধে নয়।

— পাওলো ইবারম্যান

@ পাওলো: হ্যাঁ, আমি সম্মত হই যে এসএসএল কেবল এনক্রিপশন সম্পর্কে নয়, শংসাপত্র সম্পর্কেও রয়েছে, দুর্ভাগ্যক্রমে আমি এখানে শটগুলি কল করি না, এবং লোকেরা যখন বলে যে তারা একটি নিয়মিত http://সংযোগের সাথে ওয়েবপৃষ্ঠাটি ব্যবহার করতে চান ... হতাশার বিষয়: /

— ম্যাথিউ মিঃ

@ ম্যাথিউ: এর অর্থ কি আপনি পাবলিক ওয়েব পৃষ্ঠার অংশ হিসাবে পাবলিক_কি প্রেরণ করছেন, encrypt(entered_password, public_key)ক্লায়েন্টের উপর কম্পিউটিং করছেন, এবং ফলাফলটি সার্ভারে প্রেরণ করছেন, যা সম্পাদন করে does_password_match?(user, decrypt(encrypted_password, private_key))?

— কেন ব্লুম

@ কেন: কম-বেশি, আপনি সঠিকভাবে এনক্রিপশন পেয়েছেন। পাসওয়ার্ড মেলানোর জন্য does_password_match(user, salt, decrypt(encrypted, key))এটি ব্যবহারকারীর উপর নির্ভর করে নুনের সাথে আরও বেশি । যেমনটি আমি বলেছি, সুস্পষ্ট বিষয়টি হ'ল মধ্য-মাঝারি সুরক্ষার অভাব।

— ম্যাথিউ এম।

52

এটি পরামর্শ দেবে, আপনি পাসওয়ার্ডগুলি উন্মুক্ত পাঠ্যে রাখছেন, যা কোনও সুরক্ষিত পরিস্থিতিতেও নেই which

বরং আপনার উচিত:

if(hash(enteredPassword) == storedHash)

আপনি উদাহরণস্বরূপ MD5 হিসাবে সাধারণ হ্যাশ ব্যবহার করতে পারেন

— vartec
সূত্র

22

পাসওয়ার্ডটি হ্যাশ করার জন্য +1। তবে আমি কমপক্ষে কিছুটা লবণও যোগ করব। অন্যথায়, যেহেতু ব্যবহারকারীরা সিস্টেমগুলির মধ্যে ব্যবহারকারীর নাম এবং পাসওয়ার্ড পুনরায় ব্যবহার করতে চলেছেন, আপনার নিম্ন সুরক্ষা অ্যাপ্লিকেশনটিকে লঙ্ঘন করা আক্রমণকারীকে আরও উচ্চতর সুরক্ষা অ্যাপ্লিকেশন লঙ্ঘন করতে সক্ষম করতে পারে। উদাহরণস্বরূপ, সাম্প্রতিক এইচবিগ্যারি হ্যাক তাদের ওয়েবসাইট চালিত সিএমএস সিস্টেমের সাথে সমঝোতা করে এবং অংশটিকে তাদের সার্ভারগুলিতে রুট অ্যাক্সেসে রূপান্তরিত করতে পরিচালিত হয়েছে কারণ স্বল্প-সুরক্ষা সিএমএস সিস্টেম আর্স্টেকনিকা.com/tech-policy/ এ

— জাস্টিন গুহ

1

সম্মত হন ... নিম্নলিখিতগুলি বিবেচনা করুন .. "স্ট্রিং জাভাফিল.ক্লাস | গ্রেপ-আই পাসওয়ার্ড"

— বিল

প্লেইন পাসওয়ার্ড যদি কেবল একবার ব্যবহার করা হয় তবে তাতে সমস্যা কী?

10

@ টিম কারণ ব্যবহারকারীরা কেবল একবার পাসওয়ার্ড ব্যবহার করবেন না । অধ্যয়নগুলি ধারাবাহিকভাবে দেখায় যে ব্যবহারকারীরা একাধিকবার পাসওয়ার্ডগুলি পুনরায় ব্যবহার করে (যেমন Theregister.co.uk/2011/02/10/password_re_use_study ) যতবার না বলা হয়েছে তা তারা জানায়।

— স্কট

3

@ টিম: এছাড়াও, কেবল আপনার পাঠ্য সম্পাদককে আপনার এক্সি, ডেল ইত্যাদি খুলুন এবং আপনি সম্ভবত সেখানে আপনার পাসওয়ার্ডটি দেখতে পাবেন।

— গাস কাভালকান্তি

14

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

— glenatron
সূত্র

আমি কেবলমাত্র এএসপি. নেট সদস্যপদ সরবরাহকারীদের আবিষ্কার করেছি তবে তাদের দিকে তাকিয়ে দেখছিলাম "এই জাতীয় কিছু বাস্তবায়নে আমি কতবার সময় নষ্ট করেছি?"

— গ্লেনাট্রন

8

সুরক্ষা অত্যন্ত আকর্ষণীয় বিষয়, বিশেষত কারণ আপনার ব্যবহারকারীদের অসুবিধে করা এবং তাদের তথ্য নিরাপদ কিনা তা নিশ্চিত করার মধ্যে ভারসাম্য থাকা দরকার। সাধারণত, আপনার কতটা সুরক্ষা দরকার তা সূত্র হ'ল ডেটার গুরুত্বের একটি কাজ function সংক্ষেপে:

isSecuritySufficient = effortToBreak > rewardForBreaking

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

কয়েকটি স্বল্প ব্যয় রয়েছে (ব্যবহারকারীর উপর প্রয়োগ ও প্রভাবিত করতে) বিকল্পগুলি উপলভ্য। এর মধ্যে একটি হ'ল ন্যূনতম পাসওয়ার্ডটি হ্যাশ করছে। সরল পাঠ্যে পাসওয়ার্ডের মতো সংবেদনশীল কিছু সঞ্চয় করা যে কোনও পরিষেবা হ্যাক হওয়ার কারণে বিব্রত হওয়া।

পাসওয়ার্ড সুরক্ষার জন্য সাধারণ নীতিমালা

কখনও সরল পাঠ্যে পাসওয়ার্ড সংরক্ষণ করবেন না
SHA-1 বা SHA-512 এর মতো সুরক্ষিত হ্যাশ ফাংশন ব্যবহার করে হ্যাশ (এমনকি এমডি 5 একটি ম্যাচিং হ্যাশ খুঁজে পাওয়া খুব সহজ)
একটি অ্যাপ্লিকেশন লবণের মান ব্যবহার করুন। লবণটি এলোমেলো বাইট হয় অন্যথায় অনুমান করা আরও কঠিন করার জন্য একটি পাসওয়ার্ডে যুক্ত হয়। রান্নার সময় নুন উত্পন্ন করা উচিত এবং যেকোন উপায়ে সঞ্চিত ও রেফারেন্সের চেয়ে মেশিন সম্পর্কে বীজমূল্য হিসাবে তথ্য ব্যবহার করা উচিত।
কোনও ব্যবহারকারী নির্দিষ্ট লবণের মান ব্যবহার করুন। আপনার প্রয়োগের লবণের সাথে এটি ব্যবহার করুন।
কোনও নেটওয়ার্ক জুড়ে সমস্ত প্রমাণীকরণের অনুরোধগুলি এনক্রিপ্ট করুন । তার মানে ওয়েব অ্যাপ্লিকেশনগুলির জন্য এসএসএল ব্যবহার করুন।

যেহেতু আপনি প্রমাণীকরণের জন্য এসএসএল ব্যবহার করছেন, তাই সর্বনিম্ন আপনি ব্যবহারকারীর অ্যাকাউন্টের সাথে সম্পর্কিত সমস্ত পৃষ্ঠা এনক্রিপ্ট করতে চান। এটি ব্যবহারকারীর যথাসম্ভব যথাসম্ভব সুরক্ষিত করার অনুমতি দেয়।

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

— বেরিন লরিটস
সূত্র

1

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

— ডেভিড কনরাড

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

— বেরিন লরিটস

আহ, আমি দেখছি, ডাটাবেসের বাইরে নুনের কিছু অংশ রাখুন। এটা বোঝা যায় না। ধন্যবাদ.

— ডেভিড কনরাড

আমি প্রতি সারি লবণের সঞ্চিত সমস্যা দেখতে পাচ্ছি না যতক্ষণ না তার প্রতি সারি অনন্যতা থাকে। এখানে একটি হ্যাশ রয়েছে: "fd84235a55bbfeb1585a3dd069d48127989c9753058b51b6ba2056fd6c5a0a91" (SHA256), এখানে লবণ রয়েছে: "671254bdf7944f8fa88e6c9913b948ee"। মনে হয় আপনি পাসওয়ার্ড পেতে পারেন? সেই লবণের জন্য কোনও রেইনবো টেবিল নেই (এমনকি আপনাকে লবণ দেওয়া হলেও), আপনি এটি নিষ্ঠুরতার সাথে আটকাচ্ছেন।

— ব্রায়ান বোয়েচার

3

পাসওয়ার্ড অন্য কোনও কিছুর জন্য ব্যবহার না করা হলে এটি ঠিক আছে। এখনও একটি ঝুঁকি রয়েছে যে ব্যবহারকারী সিদ্ধান্ত নিয়েছে যে সে পাসওয়ার্ডটি আবার ব্যবহার করতে পারে, তাই এটি আরও ভাল হবে:

if(hash(enteredPassword) == hashOfValidPassword)

এটি যদি নিজের বা এমন কারও পক্ষে থাকে যা সচেতন যে পাসওয়ার্ডটি সরল-পাঠ্যে সঞ্চিত আছে, তবে তা ঠিক আছে।

1

যেমন জাস্টিন গুহর ভাষায় বর্ণিত উত্তরের মন্তব্য, লবণ ব্যবহার করুন if (hash (enteredPassword + salt) == hashOfValidSaltedPassword)- এবং লক্ষ্য করুন যে এটি +সম্ভবত সংমিশ্রণ, সংযোজন নয়। এটি সত্যিই রেইনবো টেবিলের ব্যবহারকে বাধা দেয় যা সম্ভাব্য পাসওয়ার্ডের হ্যাশগুলির টেবিল।

— ডেভিড থর্নলি

আপনি যা যা যা যা পরীক্ষা করছেন তা যদি একটি হ্যাশ হয় তবে তারা কি কেবল স্ট্রিং হ্যাশের মতো একই হ্যাশ তৈরি না করা পর্যন্ত সম্ভাব্য স্ট্রিংগুলির লুপ দিয়ে চালাতে পারে না? অনেকগুলি স্ট্রিং রয়েছে যা একই হ্যাশের সাথে সামঞ্জস্য হতে পারে।

— মরগান হের্লোকার

@ প্রোফ প্লাম: হ্যাশিং অ্যালগরিদম ভাল থাকলে সংঘর্ষগুলি খুঁজে পাওয়া খুব কঠিন। এটি আধুনিক ক্রিপ্টোগ্রাফির ভিত্তি: এগুলি মূলত একমুখী ফাংশন।

3

উত্স কোড পাওয়া যায়? তা না হলেও, আমি নিশ্চিত বাইনারি উপলভ্য থাকলে মেশিনের নির্দেশাবলীতে পাসওয়ার্ডটি পাওয়া যাবে quite আমি চেকসাম করার এবং তার পরিবর্তে তুলনা করার পরামর্শ দেব।

সুরক্ষা এটি আপনার মতে খুব গুরুত্বপূর্ণ না হলেও কখনই উপেক্ষা করবেন না।

— Anto
সূত্র

2

হ্যাঁ, খারাপ ধারণা যদি এটি কোনও ওপেন সোর্স প্রকল্প হয় :)

-1 - যদি আপনি মনে করেন যে উত্সটি থাকা কোনও পার্থক্য করে তবে আপনি সুরক্ষা সম্পর্কে কিছুই জানেন না।

— ম্যাটনজ

1

একেবারে না. একটি পড়া আছে এই , এটা বর্ণনা কিভাবে হ্যাকার একটি নিরাপত্তা ওয়েব সাইটটি হ্যাক। আপনি পরিকল্পনা করেন যে আপনি চেইনের দুর্বল লিঙ্ক হিসাবে থাকবেন।

— ডেভ
সূত্র

0

এটি বেশ কয়েকটি উত্তরে লক্ষ করা গেছে যে আপনার নিজের পাসওয়ার্ডটি নিজেই সঞ্চয় করা উচিত নয়, তবে একটি হ্যাশ - এবং আপনার এসএসএল ব্যবহার করা উচিত।

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

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

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

— পিট
সূত্র

-2

যতক্ষণ না এটি সার্ভারের পাশে ... তবে হ্যাঁ।

আপনি যদি আরও কিছু সিকিউরিটি চান তবে https- এ এনক্রিপ্ট করুন এবং ডিবিতে পাসওয়ার্ড এনক্রিপ্ট করুন।

— morons
সূত্র

3

কেন এটি একটি ওয়েব অ্যাপ্লিকেশন অনুমান?

— ক্রিস

ভাল যুক্তি! আমি করেছি.

— মরনস

4

-1 এটি সার্ভার সাইড থাকলেও এটি এখনও ঠিক নেই।

— GSto

একটি 'যদি পাসওয়ার্ড == XXXXXXX' ন্যূনতম সুরক্ষার জন্য যথেষ্ট?

এসএসএল ছাড়া না

সাইট প্রশাসকরা সন্দেহ হলে নয়

প্রশাসকের কাছ থেকে পাসওয়ার্ডগুলি সুরক্ষিত রাখার একটি উপায়