توکن امنیتی کلاینت معتبر نمی باشد. مجددا لاگین کنید

توکن امنیتی کلاینت معتبر نمی باشد. مجددا لاگین کنید را از سایت هاب گرام دریافت کنید.

سؤالات متداول توکن امضای دیجیتال ePass3003

مرحله 1: پس از اتصال توکن ، برنامه  EnterSafe PKI Manager را از طریق دابل کلیک روی آیکن مشخص شده کنار ساعت سیستم اجرا کنید.در صورت عدم مشاهده آیکن میتوانید برنامه را از طریق آدرس زیر اجرا کنید:

ویندوز 32 بیتی : C:\Program Files\EnterSafe\ePass3003\ ePassManager_3003.exe

ویندوز 64 بیتی :  C:\Program Files (x86)\EnterSafe\ePass3003\ ePassManager_3003.exe

مرحله 2: دکمه Login  را کلیک کنید.

مرحله 3: رمز توکن (که به صورت پیش فرض 1234 هست) را وارد کنید و OK را کلیک کنید.

مرحله 4: پس از ورود موفق به توکن در سمت چپ پنجره و در قسمت TokenList اطلاعات توکن شما شامل: نام توکن، نام گواهی مخصوص شما (Certificate) و PublicKey، PrivateKey نمایان خواهد شد که با کلیک نمودن بر روی هر کدام، باید اطلاعات مربوط به آنها در بخش زیرین همان قسمت ظاهر شود.

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

روش های احراز هویت توکن بیس لاگین کاربر (راهنمای عملی روش های OAuth2)

چجوری OAuth 2.0 کار می کنه و کدام روش رو انتخاب کنیم؟

پیش نوشت۱: ۱۰ یا ۱۱ ماه پیش بود که می خواستم بخش لاگین چندپر رو با نود جی اس بنویسم...خب اون موقع من مبتدی بودم و در حال یادگیری (هنوز هم هستم) به هر صورت با JWT و روشی توکن بیس ابداعی چیز بدی از آب در نیومد ولی همین چند وقت پیش مقاله ای رو توی سایت Medium دیدم که خیلی ساده و عالی این موضوع رو توضیح داده. من هم تصمیم گرفتم ترجمه اش بکنم تا هم خودم بهتر یاد بگیرم و این که شاید به درد کسای دیگه ای بخوره تا مثل من توی انبوهی از روش های پیچیده ی لاگین سردرگم نشن! از خط بعدی ترجمه ی بنده از متن اصلی مقاله مربوطه هست که می خوانید:

پیش نوشت۲: هم من و هم شمایی که داری می خونی احتمال زیاد برنامه نویسی می کنی و خب ... ! کد می خوایم ولی به هر حال هدف این نوشته نیست ولی می تونه فضایی فراهم بشه برای پرسش و پاسخ و جستجوی هدفمند

این مقاله نمی خواد که راهنمای کاملی برای OAuth 2.0 باشه بلکه تنها یک مقدمه ای برای نشان دادن مسیر های کاربران و این که چه مراحلی توی OAtuth 2 برای کاربر هست تا لاگین بکنه. ما می خواهیم با مشاهده و بررسی ۴ چارچوب در قالب مثال این موضوع رو به بررسی کنیم. و در نهایت هدف این نوشته این است که بتوانیم بهترین روش رو برای پروژه مون انتخاب کنیم.

آن چه که تا بحال من متوجه شدم و از بزرگان این حوزه فراگرفتم! به طور کلی می توانیم ۴ ورژن یا روش اجرای OAuth 2.0 را نام ببریم. البته بدین معنا نیست که باید همه ی این روش ها رو اجرا کنیم بلکه یکی از این موارد کافیست. نکته اینجاست که هدف مشترک این ۴ روش به درست آوردن access token و استفاده ی از آن برای دسترسی به اطلاعات و احراز هویت است. همین و بس... این ۴ روش به شرح زیر است:

کد مجوز (Authorization Code Grant)

این مسیر احزار هویت کامل ترین و پیچیده ترین روش از انواع روش های OAuth2 است. مراحل لاگین در دو مرحله و با تضمین حد بالایی از امنیت انجام می شود.

بیاید به همراه جزییات نحوه ی کار این روش لاگین رو در ادامه بررسی کنیم:

۱- کاربر می خواهد لاگین کند

یک سناریوی کلاسیک برای این روش توسط کاربر در مرورگر اجرا می شه. کاربر روی دکمه ی «لاگین با OAuth» کلیک می کنه و درخواست کاربر توسط کلاینت (در این مثال سایت) به سمت سرور احراز هویت ارسال می شه.

۲- کاربر به سرور احراز هویت منتقل (redirect) می شود

کلاینت درخواست لاگین رو به سرور احراز هویت می فرستد. این request به صورت فرم HTTP redirect و اطلاعات آن با متد GET به این سرور ارسال می شود (به مثال زیر توجه کنید)

پارامتر های ارسالی:

۳- اعتبار سنجی درخواست لاگین (Request validation)

سرور احراز هویت بایستی تمامی پارامتر های لاگین را بررسی کند:

پیشاپیش ذخیره ی کلاینت های در دسترس برای بررسی و هندل کردن این موارد ضروری است. و البته نگه داری و مدیریت اطلاعات کلاینت ها از حیطه ی وظایف OAuth خارج است.

۴- فرم لاگین

سرور احراز هویت فرم لاگین را به کاربر نشان می دهد و کاربر نام کاربری و رمز عبور خود را برای ورود به برنامه وارد می کند (مرحله ی ۵ در عکس)

بعد از بررسی اطلاعات توسط سرور احراز هویت (مرحله ی ۶ در عکس) اجازه ی دسترسی به scope مشخص شده را به کاربر می دهد و request خارج از اون scope تعیین شده مجاز نیست (چون ممکنه در استفاده از اپلیکیشن محدود شده باشه)

۵- انتقال (redirect) به کلاینت با کد مجوز authorization_code

سرور احراز هویت کد authorization code را ایجاد می کند و آن را روی redirect_url تعیین شده به سمت کلاینت بر می گرداند.

تمامی این مراحل در سمت کلاینت اتفاق می افتد (روی مرورگر یا اپلیکیشن موبایل) و در تمامی این مراحل کلاینت باید با بک اند در ارتباط باشد.

یه نظر من این موارد یکی از مهم ترین جنبه های انتخاب روش مناسب OAuth 2.0 برای پروژه هاست که یبا نیاز هامون منطبق بشه.

۸ , ۹- اعتبار سنجی کد مجوز (authorization code)

در اینجا کلاینت باید سرور احراز هویت را برای بررسی کد دریافت شده فراخوانی کند. برای این کار ارسال پارامتر های زیر لازم است:

سرور احراز هویت تمامی اطلاعات بالا را از جهت صحت داشتن و همخوانی بررسی می کند. بررسی کد مربوطه باید از جهات کامل بودن و خطر دار نبودن و منتقضی نبودن و تعلق داشتن به کلاینت بررسی شود.

۱۰- کلاینت access_token را دریافت می کند

سرور احراز هویت access_token را ایجاد کی کند و آن را به سمت کلاینت بر می گرداند. انواع مختلفی برای ایجاد توکن وجود دارد. این ها می توانند تاریخ انقضا داشته باشند یا رفرش شوند. عموما همراه access_token اطلاعات زیر نیز به کلاینت برگردانده می شود:

۱۱- کلاینت از access_token استفاده می کند

از این مرحله به بعد کلاینت access_token رو دریافت کرده و از آن برای دسترسی و شناسایی توسط سرور منابع (همون جایی که اطلاعات رو از دیتابیس می گیره و به کلاینت بر می گردونه) مورد استفاده قرار می گیرد.

سرور منابع یک بخشی از وب اپلیکیشن سمت سرور ماست که فرقی نمی کنه که از چه نوعی باشه می تونه RESRT API یا SOAP یا هر چیز دیگه ای باشه ... متد درخواست تغییر access_token بستگی به نوع منابع تون داره. متد متداول استفاده از REST API هست (در حال حاظر) با بهره گیری از HTTP header:

مثال (در هدر قرار گرفته است):

۱۲ و ۱۳- اعتبار سنجی توکن

هر وقتی که سرور منابع درخواستی را دریافت می کند بایستی توکن از لحاظ اعتبار خود توکن و کلاینت آن اطمینان حاصل کند.

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

به هر حال به معماری برنامه تون بستگی داره و در سمت کلاینت تفاوتی نشون داده نمی شه. اگر می خواید از روش OAuth برای احراز هویت کاربران استفاده کنید بهتره به نمونه های مربوط به نوع معماری برنامه تون مراجعه کنید تا انتخاب آگاهانه تر و کد های مناسب تری داشته باشید.

۱۴ و ۱۵- دسترسی و نمایش منابع اختصاصی

اطلاعات مخصوص با دسترسی محدود به کلاینت در هر بار اعتبار سنجی توکن توسط سرور منابع به کاربر نمایش داده خواهد شد.

ضمنی (Implicit Grant)

این روش مشابه روش قبلی (کد مجوز) است با این تفاوت که در روش ضمنی access_token بلافاصله پس از لاگین کاربر به سمت کلاینت ارسال می شود. از این روش در Single Page Applications ها مثل انگولار یا ری اکت یا ویو جی اس (نرم افزار هایی که از فریم ورک های جاوااسکریپت استفاده می کنن) استفاده می شود چرا که امکان محرمانه نگه داشتن client_secret وجود ندارد (که در روش اول که کد مجوز بود بحث شد)

اولبن تفاوت هنگام redirect شدن به سرور احراز هویت مشاهده می شود. مقدار پارامتر response_type از code به token تغییر یافته است. این بدین معناست که نوع پاسخ سرور بایستی بلافاصله access_token باشد به جای authorization_code.

در این روش مراحل کمتری نسبت به روش قبلی برای لاگین کاربر طی می شود اما در عین حال به علت طی شدن مراحل ثبت نام در مروگر امنیت کمتری نسبت به روش قبلی (کد توکن) دارد. مثلا token رد و بدل می شود در حالی که در روش کد مجوز به این صورت نیست و توکن بین درخواست های سرور ها منتقل می شود بنابراین دسترسی یا اختلال در آن بسیار دشوارتر است.

اعتبار کلاینت (Client Credential Grant)

تفاوت اصلی این روش در این است که کاربر در مراحل احراز هویت دخیل نیست و برنامه مستقیما خودش اقدام می کند.

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

این روش در سمت سرور اجرا می شود (نه در سمت کلاینت). redirect نداریم اما یک درخواست با متد POST با پارامتر های زیر ارسال می شود.

پاسخ دریافتی از سمت سرور access_token می تواند در درخواست های از سرور منابع مورد استفاده قرار گیرد.

پسورد (Password Grant)

بحث اصلی در این روش به نظر من اینه که کاربر در مرورگر (سمت کلاینت) نام کاربری و رمز عبور خود را وارد می کنه (نه در سرور احراز هویت). نکته ای لازمه در اینجا اشاره بشه اینه که اطلاعات محرمانه (credentials) به سرور احراز هویت تعلق داره نه به کلاینت.

این نکته بدین معناست که کاربر باید به طور کامل از جهت ارسال اطلاعات به سرور احراز هویت معتبر اطمینان حاصل کنه. برای فهم بهتر تصور کنید که برنامه ی شما قابلیت ثبت نام با اکانت فیسبوک را دارد این در حالی است که کاربر بایستی نام کاربری و رمز عبور اکانت فیسبوک خود را در برنامه شما وارد کنید. اگر شما جای این کاربر بودید چه می کردید؟ (خب ... ! اطلاعاتم رو وارد سایته می کردم!) در این وضعیت باید از جعلی نبودن سایت و عدم ذخیره یا تغییر در رمز عبور و نام کاربری اکانت فیسبوک خود توسط سایت اطمینان خاطر پیدا کنید.

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

در یک مرحله نام کاربری و رمز عبور توسط سمت کلاینت (فرانت) دریافت و به سمت سرور (بک اند) ارسال می شود. با استفاده از متد POST و پارامتر های زیر این درخواست انجام می شود:

مثال:

سرور احراز هویت پس از بررسی نام کاربری و رمز عبور access_token را به کلاینت برمی گرداند.

در این روش به دخالت هر دو سمت سرور و کاتینت نیاز است.

عملیاتی کردن OAuth 2

برای اجرای OAuth 2 به همکاری و توسعه در هر دو سمت کلاینت و سرور در زمینه های زیر نیاز است:

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

فریم ورک ها و زبان های برنامه ویسی زیادی هستند که OAuth رو اجرا می کنن. این امر کارو در اجرای روش و اعتبار سنحی هایی که نیاز دارید (طرح کلی و کد های مربوط) راحت تر می کنه. اما من به ندرت راه حل های «هلو برو تو گلو !» (مثل آب خوردن) پیدا کردم.

یک چالش در اجرا می تواند پیکربندی و مدیریت کلاینت های متفاوت باشد که تنها با تصور کردن این موضوع می توانید به سرعت این نکته رو تصدیق کنید.

علاوه بر آن باید به scope و سطوح دسترسی مجوز های کاربران نیز توجه کنید. جای مدیریت این موضوع هر جایی می تونه باشه ولی ظریف تر این است که در مرحله ی حفاظت از منابع (در سرور منابع) اجرا شود.

نکته ی دیگر مزایای مدیریت token هاست که مانند یک دیتابیس عمل می کند و قابلیت ذخیره ی یک دوره ی کامل چرخه ی حیات کاربر را داراست.

بالاخره از کدام روش استفاده کنیم؟

انتخاب روش درست به عوامل متعددی بستگی داره. پاسخ به این سوالات می تواند به انتخاب درست شما منجر شود.

آیا شما می توانید client_secret را به صورت امن نگهداری کنید؟

بله: سوال بعدی

خیر: روش ضمنی IMPLICIT GRANT

آیا برنامه ی شما وب اپلیکیشن است؟

بله: سوال بعدی

خیر: روش کد مجوز CLIENT CREDENTIAL GRANT

آیا کاربر اعتماد کافی جهت ورود اطلاعات محرمانه ی کاربری خود را دارد؟

بله: روش پسورد PASSWORD GRANT

خیر: روش CLIENT CREDENTIAL GRANT

نتیجه گیری

امیدوارم این مقاله به دردتون خورده باشه و تبریک می گم که به آخرش رسیدید و این برای من بدین معناست که این نوشته به درد خیلیا خورده و تونسته کمکی هر چند کوچک به شمار بیاد.

منبع: An OAuth 2.0 introduction for beginners

پس نوشت۱: منم خیلی خوشحالم که بالاخره ترجمش تموم شد چون حدود یک ماه طول کشید (هفته ای یه روز وقت گذاشتم) و هر بخش رو هم که ببینید لحن متن متناسب با حال اون موقع من متفاوته! و البته می دونم کیفیت پایینی هم داره :o

پس نوشت۲: اخیرا یک آهنگی گیر آوردم که برام خیلی جذاب بود از لحاظ معنی و مفهومش. می گه که روزا می گذره و اینو همه هم می دونن ولی تو نصف عمرت رو می خوای از هر کسی یاد بگیری و در نهایت خدا تو رو به اون چیزی که تو رویاهات هست می رسونه...لینک soundcloud به این آهنگ Dream On - Aerosmith

موفق باشید ... فقط همین!

توکن امنیتی

توکِن امنیتی سخت‌افزاری کوچک است که برای ورود کاربر یک سرویس رایانه‌ای به سامانه به‌کار می‌رود. به عبارت دیگر، این دستگاه یک دستگاه فیزیکی است که در اختیار کاربران مجاز قرار می‌گیرد تا به راحتی بتوانند برای استفاده از یک سیستم کامپیوتری هویت آن‌ها تشخیص داده شود. توکن امنیتی برای اثبات هویت فرد به صورت الکترونیکی استفاده می‌شود.(به عنوان مثال نحوه دسترسی به حساب بانکی از راه دور). از توکن به علاوه یا به جای رمز عبور معمولی برای احراز هویت مشتری که خواهان ورود به سیستم است، بهره می‌برند. به عبارت دیگر به عنوان یک کلید الکترونیکی برای دسترسی عمل می‌کند.

بعضی از توکن‌ها کلیدهای رمزنگاری مانند امضا دیجیتال و اطلاعات بیومتریک مثل اثرانگشت را در حافظه خود ذخیره می‌کنند.[۱] این توکن‌ها شامل چند کلید برای وارد کردن پین‌کد یا شماره شناسایی شخصی) و آغاز برنامه توکن برای انجام عملیات ایجاد رمز عبور هستند. طراحی مخصوصی از این توکن به صورت ارتباط USB و بلوتوث است که این روش‌ها در انتقال کلید رمز تولید شده به سیستم دخالت دارند.

انواع نشانه و موارد استفاده[ویرایش]

چهار گونه نشانهٔ امنیتی وجود دارد:

در این نوشته منظور نوع دوم نشانه‌است.

ساده‌ترین نوع نشانه نیاز به اتصال به کامپیوتر ندارد. مشتری اعداد را به وسیله صفحه کلیدی که روی صفحه نمایش وجود دارد وارد می‌کند و سپس شماره شناسایی شخصی یا PIN code برای ورود به نشانه را زده وارد می‌شود. هرچند قطع شدن از سرور احراز هویت باعث می‌شود که نشانه‌ها در مقابل حملات میانی آسیب‌پذیر باشند.

بعضی از نشانه‌ها به وسیله اتصالات بی سیم به کامپیوتر وصل می‌شوند، مانند بلوتوث. این نوع نشانه‌ها دنباله‌ای از کلید را به مشتری محلی یا نزدیک‌ترین نقطه دسترسی انتقال می‌دهند.

نوع دیگر نشانه که امروز خیلی کاربرد وسیعی دارد، تلفن‌های همراه هستند که از ارتباطات در سطح کانال‌های out-of-band مثل صدا، پیام کوتاه، USSD و... استفاده می‌کند. این نوع نشانه نیز همانند نشانه‌های غیر متصل فیزیکی (نوع اول) در مقابل حملات میانی آسیب‌پذیر هستند.

در نشانه‌هایی که باید به کامپیوتر متصل شوند، باید موارد زیر را در نظر گرفت:

وابسته به نوع نشانه، سیستم عامل کامپیوتر باید:

در پایان، یک روش دسترسی به نشانه که نشانه مجازی نامیده می‌شود، به برقراری ارتباط http/https در پروتکل اینترنت برای تبادل اطلاعات نشانه و کلید امضای دیجیتال با سایر دستگاه‌های متصل به اینترنت، تکیه دارد. این روش باعث کاهش خطرات ناشی از حملات میانی و کاهش هزینه‌های حمایتی می‌شود. یک کاربرد مرتبط استفاده از سخت افزار دانگل (Dongle) است. بعضی برنامه‌ها برای اثبات نرم‌افزارهای مرتبط یه سخت افزار نیاز دارند. دانگل در قسمت ورودی دستگاه قرار می‌گیرد و نرم‌افزار هنگام دسترسی به دستگاه‌های ورودی و خروجی (I/O) از سوالات احراز هویت نرم‌افزار استفاده می‌کند و مجاز شمرده شده و سپس دسترسی قابل قبول است.

حداقل نیازمندی[ویرایش]

مورد اول (برای راه اندازی اولیه و نشانه‌های مستثنی). کمترین نیازمندی هر نشانه داشتن یک مشخصه منحصربه‌فرد ذاتی است که در حافظه ذخیره شده‌است. این حافظه قابل دستکاری نیست و به بیان بهتر به گونه‌ای طراحی شده‌است که به صورت باز برای سایر کاربردهایی که توسط فروشندگان نشانه و سازمان‌های دیگر ارائه می‌شود، در دسترس نیست.

مورد دوم (برای نشانه‌های out-of-band). کمترین نیازمندی در این نوع، اتصال به رسانه‌هایی مشابه شبکه‌های موبایل برای USSD، پیام کوتاه و صدا است، که تمام چیزهایی که نیاز است در شماره موبایل یا تلفن ثبت شده‌است.

آسیب پذیری[ویرایش]

ساده‌ترین مورد آسیب پذیری در وسایلی که شامل رمز هستند، گم شدن دستگاه کلید مخصوص یا فعال‌کننده تلفن هوشمند با توابع جامعیت کلید است. نشانه‌های غیرمتصل و نشانه‌هایی که از out-of-band استفاده می‌کنند، در مقابل حملات میانی آسیب‌پذیر هستند. در این نوع حمله، فرد کلاهبردار به عنوان یک عنصر میانی بین کاربر (نشانه) و سیستم اصلی (احراز هویت) قرار می‌گیرد. سپس مقدار نشانه را از کاربر درخواست کرده و خودش آن را به سیستم احراز هویت تحویل می‌دهد و خود را به جای کاربر نشانه جا می‌زند. تا زمانیکه مقدار نشانه از نظر ریاضی درست باشد، احراز هویت با موفقیت انجام می‌شود و فرد کلاهبردار قادر به دسترسی است. در سال ۲۰۰۶، Citibank اعلام کرد که کاربران سخت افزارهایی که بر اساس نشانه کار می‌کردند، قربانی حمله میانی توسط افراد اوکراینی گردیده‌اند.

امضای دیجیتال[ویرایش]

امضای دیجیتال به اندازه امضای دستی قابل اطمینان است. برای ساخت امضای دیجیتال نیاز به یک کلید خصوصی است که فقط خود فرد مجاز آن را می‌داند. نشانه‌ها با انجام عملیات تولید مطمئن و ذخیره کلید خصوصی امضای دیجیتال را امن می‌کنند. به این ترتیب برای احراز هویت قابل استفاده‌است. چون همانطور که گفته شد کلید خصوصی نشانه‌ای بر شخصیت فرد و یگانه بودن آن است. نشانه‌هایی که برای احراز هویت استفاده می‌شوند باید یک شماره خاص و یکتا داشته باشند. تمام روش‌های نشانه برای امضای دیجیتال به مسائل و قوانین ملیتی مناسب نیستند. نشانه‌هایی که صفحه کلید ندارند یا از اینترفیس‌های(به انگلیسی: Interface) دیگری استفاده می‌کنند برای سناریو امضا مناسب نیستند.

انواع نشانه‌های سخت افزاری و نرم‌افزاری[ویرایش]

بعضی از نشانه‌های امنیتی هم به صورت سخت افزاری و هم به صورت نرم‌افزاری در دسترس هستند. اگر فردی به این دو نوع نشانه امنیتی نگاه کند، از لحاظ ساختاری یکسان به نظر می‌رسند ولی در توابع یک سری تفاوت‌هایی با هم دارند.

نشانه مورد نظر هیچ گونه اتصال فیزیکی و منطقی با کامپیوتر مشتری ندارد. به‌طور معمول به دستگاه ورودی خاصی نیاز ندارند. در عوض یک صفحه نمایش داخل خود دارند که داده‌های احراز هویت به وسیله آن نمایش داده می‌شود و کاربر به صورت دستی اطلاعات را با صفحه کلید وارد می‌کند. این نوع نشانه (معمولاً همراه یک رمز عبور) برای احراز هویت در تشخیص افراد به صورت بر خط بیشتر مورد استفاده قرار می‌گیرد.

این نوع نشانه باید حتماً به صورت فیزیکی به کامپیوتر مشتری متصل گردد. نشانه‌ها در این دسته به‌طور اتوماتیک اطلاعات احراز هویت را به کامپیوتر مشتری در همان اولین ارتباط منتقل می‌کند، به جز اطلاعاتی که باید به‌طور دستی توسط کاربر داده شود. برای استفاده از این نوع نشانه باید دستگاه ورودی مناسبی روی سیستم نصب شود. معمول‌ترین نوع از نشانه‌های متصل، کارت‌های هوشمند و نشانه USB است که به ترتیب نیاز به دستگاه کارت خوان کارت هوشمند و پورت USB دارند.

بسیاری از نشانه‌های متصل از تکنولوژی کارت هوشمند استفاده می‌کنند. کارت هوشمند می‌تواند خیلی ارزان و شامل مکانیزم‌های امنیتی مطمئن باشد. (همانند آن‌هایی که توسط مؤسسه‌های مالی استفاده می‌گردد، مثل دسته چک) عملکرد محاسباتی کارت هوشمند اغغلب محدود است و آن به دلیل توان مصرفی بسیار کم آن هاست.

این نوع نشانه سومین نوع از نشانه‌های فیزیکی است. در این نوع برخلاف نشانه متصل که نیاز به اتصال فیزیکی دارد، از اتصال منطقی برای ارتباط با کامپیوتر مشتری استفاده می‌شود. به دلیل عدم استفاده از اتصال فیزیکی، این نشانه کاربردی راحت‌تر نسبت به نشانه متصل دارد. به‌طور کلی می‌توان گفت نشانه بدون تماس برای سیستم‌های ورودی بدون کلید و پرداخت الکترونیک مثل رمز سریع موبایل که از فرکانس‌های رادیویی برای اطلاعات احراز هویت استفاده می‌کنند، انتخاب مناسب تری است. این نوع نشانه چون از فرکانس‌های رادیویی استفاده می‌کند احتمال نگرانی در مسائل امنیتی آن بیشتر است. در یک بررسی مشخص شد که فرکانس‌های رادیویی مورد استفاده به راحتی قابل هک یا کپی برداری هستند. مشکل دیگر در رابطه با نشانه بدون تماس عمر بسیار محدود باتری آن است، که معمولاً ۵-۳ سال می‌باشد. در مقایسه با نشانه USB ممکن است تا ۱۰ سال باتری آن مفید کار کند. هرچند بعضی از نشانه اجازه می‌دهند برای کاهش هزینه‌ها باتری آن‌ها عوض شود.

نشانه بلوتوثی اغلب با نشانه USB ترکیب می‌شود به این ترتیب هم در حالت متصل و هم در حالت بدون تماس کار می‌کند. احراز هویت با بلوتوث به فاصله بستگی دارد و تا فاصله ۱۰ متری می‌تواند عمل کند. اگر بلوتوث در دسترس نباشد باید نشانه را به پورت USB ککامپیوتر متصل کرد. از مزیت‌های عملیات در حالت بلوتوث این است که می‌توان عمل خاتمه کار را با افزایش فاصله (از بین رفتن بلوتوث) ادغام کرد.

کاربران می‌توانند از تلفن همراه خود به عنوان نشانه امنیتی بهره ببرند. یک برنامه جاوا روی موبایل نصب می‌شود که آن توابع برای فراهم آوردن یک نشانه مخصوص را روی گوشی اجرا می‌کند. دیگر روش‌های استفاده از تلفن سلولی شامل ارسال پیام کوتاه، برانگیختن یک تلفن غیرفعال و استفاده از پروتکل‌های اینترنتی مثل HTTP/HTTPS است. چنین روش‌هایی می‌توانند به راحتی گسترش پیدا کنند و باعث کاهش هزینه‌های منطقی و حذف نیاز به نشانه‌های مجزا شوند.

جستارهای وابسته[ویرایش]

منابع[ویرایش]

جواب کاربران در نظرات پایین سایت

مهدی : نمیدونم, کاش دوستان در نظرات جواب رو بفرستن.