Нещодавно ми Voximplant поліпшували авторизацію в SDK. Подивившись на результати, я трохи засмутився, що замість простого і зрозумілого токена їх стало дві штуки: access token і refresh token. Які мало того що треба регулярно оновлювати, так ще документувати та пояснювати навчальних матеріалах. Пам'ятаючи, що в OAuth два токена потрібні в основному з-за різних сервісів, на яких вони використовуються (навіть питання на stackoverflow є), а у нас такий сервіс один, я трохи офігів і пішов на другий поверх вытрясать душі з розробників. Відповідь вийшов несподіваним. Його немає на stackoverflow. Зате він є під катом.

Читати далі →

Подвійна аутентифікація Вконтакте — секс чи імітація?

Всім привіт! Нещодавно вирішив протестувати апаратний OTP токен з можливістю перепрошивки за NFC, підключивши його до своєї з у vk.com. При цьому натрапив на недоробки в системі двофакторної аутентифікації Вконтакте, які здалися мені досить істотними. Хочу поділитися своїми спостереженнями з вами, так як в самому VK помилок не визнали. Можливо, я трохи параноїк? Цікаво, що скажете ви, хабровчане.

Читати далі →

Аутентифікація і авторизація в микросервисных додатках


Автор: В'ячеслав Михайлов, Solutions Architect

Це вступна частина матеріалу, заснованого на доповіді, прочитане мною минулого літа. Друкований матеріал передбачає більше інформації, т. к. в одній доповіді зазвичай не виходить розповісти про всі деталі.

Ми розберемося з процесом аутентифікації користувача, роботою технології єдиного входу (Single sign-on/SSO), дамо загальне подання про технології OAuth2 та принципи її роботи, не вдаючись в особливості конкретної технічної реалізації. У наступній статті як приклад вдалої реалізації ми розглянемо бібліотеку Thinktecture Identity Server v3, докладніше зупинимося на її функціональні можливості, поговоримо, як зібрати мінімальний набір компонент, необхідний для роботи в микросервисной архітектурі і гідний використання в бойовій системі. У третій частині ми покажемо, як розширювати цю бібліотеку, підлаштовуючись під потреби вашої системи, а завершить цикл статей розбір різних сценаріїв, які зустрічалися в житті багатьох розробників з рекомендаціями для кожного випадку.

Читати далі →

Витоку даних в сфері охорони здоров'я: нова чума

Служби ІТ-безпеки в галузі охорони здоров'я стикаються зі зростаючими труднощами. 2015 рік виявився настільки поганим з точки зору захисту даних пацієнтів, що Управління по цивільних прав при Міністерстві охорони здоров'я і соціального забезпечення США почало публікувати інформацію про втрату даних у галузі охорони здоров'я на так званій «Стіні ганьби». Тільки торік було зафіксовано 253 витоку в галузі охорони здоров'я, кожна з яких торкалася як мінімум 500 окремих осіб і в результаті яких було втрачено в загальній складності понад 112 мільйонів записів даних. Крім того, була зафіксована найбільша витік даних в галузі охорони здоров'я за всю історію – в результаті цієї витоку, медична страхова компанія Anthem втратила 78,8 мільйонів записів персональної інформації пацієнтів, і ще від 8,8 до 18,8 мільйонів записів, що не відносяться до пацієнтів.



Читати далі →

Чому традиційна захист від крадіжки грошових коштів у системах ДБО вразлива

Банківські електронні сервіси безпосередньо чи опосередковано оперують грошима. А там, де є гроші, завжди знайдуться ті, хто захоче їх вкрасти. Особливий інтерес у кіберзлочинців викликають системи дистанційного банківського обслуговування для юридичних осіб, так як на рахунках останніх акумулюються значні суми грошових коштів.
Для захисту від крадіжки грошових коштів у таких системах, як правило, потрібно вирішити наступні основні завдання: перевірити справжність користувача, а також автентичність та цілісність електронного документа, що виражає намір користувача. На практиці, таким документом є платіжне доручення, в числі реквізитів якого задаються сума грошових коштів і рахунок одержувача.
Ці завдання традиційно вирішуються з використанням засобів суворої двофакторної аутентифікації і електронного підпису, виконаних у вигляді USB-токенів або смарт-карт (далі – токени).
Читати далі →

Огляд децентралізованих крипто-платформ. Частина1: Waves

Цим постом ми — Web-Payment.ru — хотіли б відкрити цикл оглядів блокчейн-платформ, основна мета якого — розповісти про можливості практичного застосування технології блокчейн для побудови не тільки окремих сервісів, але і цілих цифрових екосистем. У своїх оглядах ми будемо розповідати про системи, які незаслужено обділені увагою на Хабре, але широко відомі і обговорюються в криптовалютной тусовці. У першому матеріалі циклу мова піде про open source блокчейн-платформі Waves, якої до червня цього року в рамках краудфандингової кампанії вдалося залучити фінансування в розмірі 29 445 BTC, що діяв на той момент курсом склало більше $15 млн. Я вирішив детальніше ознайомитися з функціоналом цієї децентралізованої платформи, що спеціалізується на моделі блокчейн-токенів, основними напрямами її діяльності, а також стратегічними кроками керівництва проекту.

На відміну від базується в Канаді ядра команди Ethereum і німецької команди Lisk, кістяк команди Waves працює в Москві.

Читати далі →

FIDO U2F — Універсальна Двофакторна Аутентифікація. Введення

Ні для кого не секрет, що сьогодні існує велика проблема з безпекою в інтернеті. Користувачі використовують легкі паролі і переиспользуют їх на інших ресурсах. Парольні менеджери все ще в новинку для звичайного користувача, і вашу бабусю ви навряд чи змусите використовувати випадкові одноразові паролі з високою ентропією. Життя тлін і біль...
На світанку веб2.0 ми стали розуміти, що паролів недостатньо і винайшли двофакторну аутентифікацію або 2FA.
Що з себе представляють 2FA рішення сьогодні?
  • SMS — одноразові паролі надіслані за допомогою SMS.
  • OTP(TOTP/HOTP) — одноразові паролі, згенеровані на основі майстер ключів. Приклади: Google Authenticator, Yubikey, банківські OTP токени.
  • Криптографічні Токени — апаратні засоби для багатофакторної аутентифікації користувачів. Приклади: RSA SecureID, Рутокен.
При великому виборі рішень, у користувачів до цих пір заводять акаунти. Так чому існуючі технології не вирішили проблему?

Читати далі →

Парсим pod від Perl 5 за допомогою Perl 6

Тільки що закінчив розробку програми pod (plain old documentation) для Perl 5, написаного на Perl 6. Граматику зробити вийшло напрочуд легко – спасибі Perl 6, адже я сам-то не особливо який геній програмування. З допомогою хлопців з #perl6 я дізнався багато всього цікавого по ходу справи, і хочу поділитися цим з усіма. Ну і код, звичайно, теж додається.

До речі, рекомендую прочитати спочатку моя вступ до граматики у Perl 6, і багато чого в цій статті стане більш ясним.

Розробка граматики

В Perl 6 граматика – особливий тип класів для розбору текстів. Ідея в тому, щоб оголосити послідовність регулярок і призначити їм токени, які потім можна використовувати для розбору введення. Для Pod::Perl5::Grammar я детально пропрацював специфікацію perlpod, додаючи по мірі дослідження стандартів потрібні токени.

Звичайно, є кілька проблем. По-перше, як визначити регулярку для списків? В pod списки можуть містити списки – визначення включати себе? Виявляється, що рекурсивні визначення можливі, якщо тільки вони не збігаються з рядком нульової довжини, що приведе до нескінченного циклу. Ось визначення:

token over_back { <over>
[
<_item> | <paragraph> | <verbatim_paragraph> | <blank_line> |
<_for> | <begin_end> | <pod> | <encoding> | <over_back>
]*
<back>
}

token over { ^^\=over [\h+<[0..9]>+ ]? \n }
token _item { ^^\=item \h+ <name>
[
[ \h+ <paragraph> ]
| [ \h* \n <blank_line> <paragraph>? ]
]
}
token back { ^^\=back \h* \n }


Токен over_back описує весь список з початку до кінця. Простіше кажучи, там написано, що лист повинен починатися з =over і закінчуватися з =back, а посередині може бути багато всякого, включаючи ще один over_back!

Для простоти я зазвичай називав токени так, як вони пишуться pod, хоча іноді це не виходило з-за перетинів просторів імен.

Читати далі →