কোনও ওয়েবসাইটের প্রশাসক বিভাগ সুরক্ষিত করার জন্য সেরা অনুশীলনগুলি কী কী? [বন্ধ]

Question 1

বন্ধ এই প্রশ্নটি অফ-টপিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্ন আপডেট করুন তাই এটা -বিষয়ে স্ট্যাক ওভারফ্লো জন্য।

8 বছর আগে বন্ধ ছিল ।

আমি বিশেষত একটি প্রমাণীকরণ / অ্যাক্সেস পয়েন্টের দৃষ্টিকোণ থেকে ওয়েবসাইটগুলির প্রশাসনিক বিভাগগুলি সুরক্ষিত করার জন্য লোকেরা সর্বোত্তম অনুশীলনটি কী বিবেচনা করে তা জানতে চাই।

অবশ্যই কিছু স্পষ্ট বিষয় আছে যেমন এসএসএল ব্যবহার এবং সমস্ত অ্যাক্সেস লগ করা, তবে আমি ভাবছি ঠিক এই মূল পদক্ষেপের উপরে লোকেরা বারটি সেট করা বিবেচনা করে।

উদাহরণ স্বরূপ:

আপনি কি সাধারণ ব্যবহারকারীদের জন্য একই প্রমাণীকরণ পদ্ধতি ব্যবহার করছেন? তা না হলে কী?
আপনি কি একই 'অ্যাপ্লিকেশন ডোমেনে' অ্যাডমিন বিভাগটি চালাচ্ছেন?
প্রশাসক বিভাগটি অনাবৃত করতে আপনি কী পদক্ষেপ গ্রহণ করেন? (বা আপনি পুরো 'অস্পষ্টতা' জিনিসটি প্রত্যাখ্যান করেন)

এখনও অবধি উত্তরদাতাদের পরামর্শগুলির মধ্যে রয়েছে:

ব্রুট ফোর্স আক্রমণ প্রতিরোধ করতে প্রতিটি প্রশাসক পাসওয়ার্ড চেকের মধ্যে একটি কৃত্রিম সার্ভার-সাইড বিরতি প্রবর্তন করুন [বিকাশকারী আর্ট]
একই ডিবি টেবিল ব্যবহার করে ব্যবহারকারী এবং প্রশাসনের জন্য পৃথক লগইন পৃষ্ঠাগুলি ব্যবহার করুন (এক্সএসআরএফ এবং সেশন-চুরি বন্ধ করতে প্রশাসক অঞ্চলে প্রবেশের অনুমতি দেওয়া হয়েছে ] [চোর মাস্টার]
অ্যাডমিন অঞ্চলে (যেমন .htaccess মাধ্যমে) [চোর মাস্টার] ওয়েবসভার দেশীয় প্রমাণীকরণ যুক্ত করার বিষয়েও বিবেচনা করুন
বেশ কয়েকটি ব্যর্থ অ্যাডমিন লগইন প্রচেষ্টা [চোর মাস্টার] পরে ব্যবহারকারীদের আইপি ব্লক করার বিষয়টি বিবেচনা করুন
অ্যাডমিন লগইন প্রচেষ্টা ব্যর্থ হওয়ার পরে ক্যাপচা যোগ করুন [চোর মাস্টার]
ব্যবহারকারীদের পাশাপাশি প্রশাসকদের জন্য সমানভাবে শক্তিশালী ব্যবস্থা (উপরের কৌশলগুলি ব্যবহার করে) সরবরাহ করুন (যেমন অ্যাডমিনদের বিশেষভাবে ব্যবহার করবেন না) [লো'রিস]
দ্বিতীয় স্তরের প্রমাণীকরণ বিবেচনা করুন (যেমন ক্লায়েন্ট শংসাপত্র, স্মার্ট কার্ড, কার্ডস্পেস ইত্যাদি) [জোজিকি]
কেবলমাত্র বিশ্বস্ত আইপি / ডোমেন থেকে অ্যাক্সেসের অনুমতি দিন, সম্ভব হলে বেসিক এইচটিটিপি পাইপলাইনে (যেমন HTTPModules এর মাধ্যমে) চেক যুক্ত করুন। [জোজিকি]
[এএসপি.নেট] আইপিআরসিনাল এবং অধ্যক্ষকে লক ডাউন করুন (এগুলিকে অপরিবর্তনীয় এবং অগণনীয় করুন ) [জো জিকি]
ফেডারেট রাইটস এলভেশন - যেমন কোনও প্রশাসকের অধিকার আপগ্রেড করা হয় তখন অন্য প্রশাসকদের ইমেল করুন। [জোজিকি]
প্রশাসকদের জন্য সূক্ষ্ম-অধিকারযুক্ত অধিকারগুলি বিবেচনা করুন - যেমন ভূমিকা সম্পর্কিত ভিত্তিক অধিকারের চেয়ে অ্যাডমিনের প্রতি নির্দেশক ক্রিয়াকলাপের জন্য অধিকারগুলি সংজ্ঞায়িত করুন [জোজিকি]
প্রশাসকদের তৈরি সীমাবদ্ধ করুন - যেমন প্রশাসকগুলি অন্য প্রশাসক অ্যাকাউন্টগুলি পরিবর্তন করতে বা তৈরি করতে পারে না। এটির জন্য একটি লকডাউন 'সুপ্রেডমিন' ক্লায়েন্ট ব্যবহার করুন। [জোজিকি]
ক্লায়েন্ট সাইড এসএসএল শংসাপত্রগুলি, বা আরএসএ টাইপ কীফবস (বৈদ্যুতিন টোকেন) বিবেচনা করুন [ড্যানিয়েল পাপাসিয়ান]
যদি প্রমাণীকরণের জন্য কুকি ব্যবহার করে থাকেন তবে অ্যাডমিন বিভাগটি অন্য কোনও ডোমেনে রেখে, অ্যাডমিন এবং সাধারণ পৃষ্ঠাগুলির জন্য পৃথক কুকি ব্যবহার করুন। [ড্যানিয়েল পাপাসিয়ান]
ব্যবহারিক হলে অ্যাডমিন সাইটটিকে সরকারী ইন্টারনেট থেকে দূরে একটি ব্যক্তিগত সাবনেটে রাখার বিষয়ে বিবেচনা করুন। [জন হার্টসক]
ওয়েবসাইটের অ্যাডমিন / সাধারণ ব্যবহারের প্রসঙ্গের মধ্যে চলাকালীন লেখক / সেশন টিকিট পুনরায় বিতরণ করুন [রিচার্ড জে পি লে গুয়েন]

Question 2

এগুলি সব ভাল উত্তর ... আমি সাধারণত আমার প্রশাসনিক বিভাগগুলির জন্য কয়েকটি অতিরিক্ত স্তর যুক্ত করতে চাই। যদিও আমি একটি থিমটিতে কয়েকটি প্রকরণ ব্যবহার করেছি, তবে তারা সাধারণত নিম্নলিখিতগুলির মধ্যে একটি অন্তর্ভুক্ত করে:

দ্বিতীয় স্তরের প্রমাণীকরণ : এতে ক্লায়েন্ট শংসাপত্রগুলি (উদাহরণস্বরূপ x509 শংসাপত্র), স্মার্ট কার্ড, কার্ডস্পেস ইত্যাদি অন্তর্ভুক্ত থাকতে পারে ...
ডোমেন / আইপি বিধিনিষেধ : এই ক্ষেত্রে কেবল বিশ্বস্ত / যাচাইযোগ্য ডোমেনগুলি থেকে আসা ক্লায়েন্টরা; যেমন অভ্যন্তরীণ subnets; প্রশাসক অঞ্চলে অনুমতি দেওয়া হয়। দূরবর্তী প্রশাসকরা প্রায়শই বিশ্বস্ত ভিপিএন এন্ট্রিপয়েন্টগুলিতে যান যাতে তাদের সেশনটি যাচাইযোগ্য হয় এবং প্রায়শই পাশাপাশি আরএসএ কী দ্বারা সুরক্ষিত থাকে। আপনি যদি এএসপি.এনইটি ব্যবহার করে থাকেন তবে আপনি এইচটিটিপি পাইপলাইনে এইচটিটিপি মডিউলগুলির মাধ্যমে সহজেই এই চেকগুলি সম্পাদন করতে পারবেন যা সুরক্ষা চেকগুলি সন্তুষ্ট না হলে আপনার আবেদনটি কোনও অনুরোধ গ্রহণ করা থেকে বিরত করবে।
লক ডাউন আইপিডিয়ান্সাল এবং অধ্যক্ষ ভিত্তিক অনুমোদন : কাস্টম নীতিমালা তৈরি করা একটি সাধারণ অনুশীলন, যদিও একটি সাধারণ ভুল তাদের পরিবর্তনযোগ্য এবং / অথবা অধিকারকে গণনার যোগ্য করে তুলছে । যদিও এটি কেবল কোনও অ্যাডমিন ইস্যু নয়, এটি আরও গুরুত্বপূর্ণ কারণ এখানে ব্যবহারকারীদের উচ্চতর অধিকারের সম্ভাবনা রয়েছে। নিশ্চিত হন যে এগুলি পরিবর্তনযোগ্য এবং অগণনীয় নয়। অতিরিক্ত হিসাবে, অনুমোদনের সমস্ত মূল্যায়ন অধ্যক্ষের ভিত্তিতে করা হয়েছে তা নিশ্চিত করুন।
ফেডারেট রাইটস এলভেশন : যখন কোনও অ্যাকাউন্ট নির্বাচিত কয়েকটি সংখ্যক অধিকার পায়, তখন সমস্ত প্রশাসক এবং সুরক্ষা অফিসারকে তাত্ক্ষণিক ইমেলের মাধ্যমে অবহিত করা হয়। এটি নিশ্চিত করে যে কোনও আক্রমণকারী যদি অধিকারগুলি উন্নত করে তবে আমরা এখনই জানি। এই অধিকারগুলি সাধারণত প্রাইভেলজড রাইটস, গোপনীয়তা সুরক্ষিত তথ্য এবং / অথবা আর্থিক তথ্য (যেমন ক্রেডিট কার্ড) দেখার অধিকারগুলি ঘিরে থাকে olve
অ্যাডমিনিস্টারেও কিছুটা স্বল্প পরিমাণে ইস্যু করুন : অবশেষে এবং এটি কিছু দোকানের জন্য আরও কিছুটা অগ্রসর হতে পারে। অনুমোদনের অধিকারগুলি যথাসম্ভব বিচক্ষণ হওয়া উচিত এবং প্রকৃত কার্যকরী আচরণগুলি ঘিরে রাখা উচিত। সাধারণ ভূমিকা-ভিত্তিক সুরক্ষা (আরবিএস) পদ্ধতির একটি গ্রুপ মানসিকতা থাকে। সুরক্ষা দৃষ্টিকোণ থেকে এটি সেরা প্যাটার্ন নয়। ' ইউজার ম্যানেজার ' এর মতো ' গ্রুপ ' এর পরিবর্তে এটিকে আরও ভেঙে দেওয়ার চেষ্টা করুন ( উদাঃ ব্যবহারকারী তৈরি করুন, ব্যবহারকারীকে অনুমোদন দিন, অ্যালভেট করুন / অ্যাক্সেসের অধিকার প্রত্যাহার করুন, ইত্যাদি ...))। প্রশাসনের দিক থেকে এটিতে আরও কিছুটা ওভারহেড থাকতে পারে তবে এটি আপনাকে কেবলমাত্র বৃহত্তর অ্যাডমিন গোষ্ঠী দ্বারা প্রয়োজনীয় অধিকারগুলি অর্পণ করতে নমনীয়তা দেয়। অ্যাক্সেসে আপোস করা হলে কমপক্ষে তারা সমস্ত অধিকার নাও পেতে পারেন। আমি এটি নেট অ্যাক্সেস সিকিউরিটি (সিএএস) .NET এবং জাভা দ্বারা সমর্থিত অনুমতিগুলিতে গুটিয়ে রাখতে চাই, তবে এটি এই উত্তরের বাইরে নয়। আরও একটি বিষয় ... একটি অ্যাপ্লিকেশনে প্রশাসকরা অন্যান্য প্রশাসক অ্যাকাউন্ট পরিবর্তন করতে বা কোনও ব্যবহারকারীকে প্রশাসক করতে পারে না। এটি কেবলমাত্র একটি লক ডাউন ক্লায়েন্টের মাধ্যমেই করা যেতে পারে যা কেবলমাত্র দু'জন লোক অ্যাক্সেস করতে পারে।

Question 3

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

তদ্ব্যতীত, যদি অ্যাডমিন বিভাগটি একটি পৃথক উপ-ডিরেক্টরিতে থাকে তবে ওয়েবসভারের প্রমাণীকরণের সাথে সেটি সিকিউর করে (উদাহরণস্বরূপ অ্যাপাচে হিট্যাক্সেস) একটি ভাল ধারণা হতে পারে - তবে কারও কাছে সেই পাসওয়ার্ড এবং ব্যবহারকারীর পাসওয়ার্ড উভয়েরই প্রয়োজন।

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

3 টি ব্যর্থ লগইন হওয়ার পরে ব্যবহারকারীর আইপি ব্লক করা বা ব্যর্থ লগইনের পরে একটি ক্যাপচা প্রয়োজন (যেমন লগইন ব্যবহারকারীদের জন্য অত্যন্ত বিরক্তিকর হিসাবে প্রথম লগইনের জন্য নয়) এর মতো একটি নিষ্ঠুর শক্তি সুরক্ষাও কার্যকর হতে পারে।

Question 4

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

হ্যাঁ, এটি লেখার পরে, আমি বুঝতে পারি যে এই উত্তরটি "অ্যাডমিন লগইনের জন্য বিশেষ কিছু নয়, সেগুলি সমস্ত সুরক্ষা বৈশিষ্ট্য যা কোনও লগইনের জন্য ব্যবহার করা উচিত" হিসাবে সংক্ষিপ্ত করা যেতে পারে।

Question 5

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

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

Question 6

একটি ভাল অ্যাডমিন পাসওয়ার্ড আছে।

না "123456"কিন্তু বর্ণ, সংখ্যা এবং বিশেষ অক্ষর দীর্ঘ যথেষ্ট একটি ক্রম, বলতে 15-20 অক্ষর। ভালো লেগেছে "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>"।

ব্রুট ফোর্স আক্রমণ প্রতিরোধ করতে প্রতিটি পাসওয়ার্ড চেকের জন্য একটি বিরতি যুক্ত করুন।

Question 7

এখানে আরও কিছু বিষয় বিবেচনা করতে হবে:

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

Question 8

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

Question 9

কঠোর উপায় হ'ল ডাটাবেস, সার্ভার এবং সমস্ত সহ দুটি সম্পূর্ণ ভিন্ন "খামার" থাকা এবং ডেটা এক ফার্ম থেকে অন্য ফার্মে স্থানান্তর করা। বেশিরভাগ আধুনিক, বৃহত আকারের সিস্টেমগুলি এই পদ্ধতির ব্যবহার করে (ভিগনেট, শেয়ারপয়েন্ট ইত্যাদি)। এটি সাধারণত বিভিন্ন পর্যায়ে "সম্পাদনার মঞ্চ" -> "প্রাকদর্শন পর্যায়" -> "বিতরণ পর্যায়ে" হিসাবে বিবেচিত হয়। এই পদ্ধতিটি আপনাকে কোড (dev-> qa-> প্রোড) এর সাথে একইভাবে সামগ্রী / কনফিগারেশনকে চিকিত্সা করতে দেয়।

আপনি যদি কম ভৌতিক হয়ে থাকেন তবে আপনার কাছে একটি একক ডাটাবেস থাকতে পারে তবে কেবলমাত্র "সম্পাদনা" সার্ভারগুলিতে আপনার প্রশাসক বিভাগ উপলব্ধ। আমি বলতে চাইছি কেবল সম্পাদনা স্ক্রিপ্ট / ফাইলগুলি সম্পাদনা সার্ভারে রেখে দেওয়া হয়েছে।

স্বাভাবিকভাবেই সম্পাদনার পর্যায়ে কেবল স্থানীয় ইন্ট্রানেট এবং / অথবা কোনও ভিপিএন ব্যবহার করা উচিত।

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

মনে রাখবেন যে "শক্তিশালী অ্যাডমিন পাসওয়ার্ড রয়েছে" এর মতো জিনিসগুলি দুর্দান্ত তবে তবুও আপনার প্রশাসককে সব ধরণের স্মার্ট আক্রমণগুলির জন্য উন্মুক্ত রেখে দেয়।

Question 10

আপনি কোন ধরণের ডেটা রক্ষা করতে চান (আইনি প্রয়োজনীয়তা এবং এই জাতীয়) এর উপর এটি অনেকটাই নির্ভর করে।

প্রচুর পরামর্শ প্রমাণীকরণ সম্পর্কে .. আমার মনে হয় আপনার ওপেনআইডি / ফেসবুক প্রমাণীকরণটি লগইন হিসাবে ব্যবহার করা উচিত। (তারা সম্ভবত প্রমাণীকরণ সুরক্ষায় আরও সংস্থান ব্যয় করবে)
ডাটাবেসে মান আপডেট করার পাশাপাশি পরিবর্তনগুলি সংরক্ষণ করুন। এইভাবে আপনি ব্যবহারকারীর এক্স থেকে বা তারিখ এক্স এবং ওয়াইয়ের মধ্যে পরিবর্তন আনতে পারেন।

Question 11

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

Question 12

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

সম্ভবত আপনি প্রশাসনের বিভাগটি সর্বদা একটি বড় ডিরেক্টরিতে রেখে দিতে পারেন, যেমন

http://domain.com/sub/sub/sub/sub/sub/index.php

তবে এটি আসলে ভাল না।

সম্ভবত আপনি হোম পৃষ্ঠায় একটি প্রশ্নের স্ট্রিং অন্তর্ভুক্ত করতে পারে, যেমন:

http://domain.com/index.php?display=true

এটি হয়ে গেলে, ব্যবহারকারীর নাম এবং পাসওয়ার্ড ক্ষেত্র উপস্থিত হবে।