Епизод 5 на Nerds2Nerds записан на 16.06.2013 с основна тема криптография в web с гост gat3way.
Част 1 – обзор на новините
Директен линк към част 1 (mp3) (ogg)
00:00 – Представяне на госта
02:00 – Рожденият ден на анимирания GIF
03:00 – Apple, новият iOS, новият Mac… Май не е точно това, което хората очакваха.
19:30 – Microsoft „загубиха“ Е3
50:00 – PRISM, Mozilla и Startpage
51:30 – Facebook вече има #hashtags
54:50 – Google Glass voice search
57:10 – Microsoft ще се опитат да подпомогнат разработчиците на приложения за Windows Phone (Stilgar: в подкаста казвам, че съм гледал офертата и не си струва, но се оказва, че съм гледал предишна оферта, а за тази няма официална информация. Може би в крайна сметка ще си струва.)
59:40 – Microsoft с патент за пренос на информация през тялото
1:01:30 – Google Loon
1:05:30 – MariaDB започва да измества MySQL
1:09:30 – Chemtrails – може и да има доза истина в цялата работа
Част 2 – криптография в web и не само
Директен линк към част 2 (mp3) (ogg)
В този епизод имахме повече технически проблеми от обикновено. Ако има странни звуци от това ще да е.
юни 16th, 2013 at 23:44
Ура! Гейта е тук!!!
юни 17th, 2013 at 02:21
Ухааа, get3way 🙂 Определено този епизод ще да ми е любимия от всичките епизоди и други подкастове на света 🙂
юни 17th, 2013 at 02:45
😀 На мен ли ми се струва така или има леко притеснение в гостите 🙂
Както и да е. Евала за тия епизоди: 2 часа и нещо – на това му се вика седмичен подкаст 😛
Имате леки разминавания по отношение на въпроси-отговори, но това е положението – никой не е казал, че ще е само лесно. Разминаването на гледните точки и леките технически проблеми (ехо/закъснение и т.н.) са част от всеки подобен проект в началото. Да не говорим, че вие си водите в стил предаване и сте цели трима събеседника. С времето ще се отракате както се казва.
Имам едно питане – skype ли ползвате за комуникация, защото се чуват такива звуци и ако не е с него, тогава какво ползвате за целта? И също така, бихте ли пробвали различни начини или за сега нямате възможност като свободно време/ресурс?
юни 17th, 2013 at 03:18
Skype ползваме. Да бяхме само ние да ползваме някакъв по-специален софтуер, но за гостите не може да очакваме, че ще имат или ще се навият да инсталират каквото им кажем, а Skype всеки има под някаква форма
юни 17th, 2013 at 04:51
А да попитам възможно ли е при md5, sha1 или друг подобен ограничен от дължината си hash, 2 различни низа криптирани с един и същ алгоритъм да изплюят еднакъв hash?
Малко тъпо се изразих, но мисля че ме разбрахте.
юни 17th, 2013 at 06:56
Аз нямам. Значи няма да Ви гостувам.
юни 17th, 2013 at 08:03
По между другото през цялото време се чудих как не се сетихте, че те също публикуват игри. Направили са го за себе си.
юни 17th, 2013 at 08:27
Игрите които MS публикуват не могат икономически да оправдаят цялата свинщина. Дори и да направят 2 пъти повече пари от тея игри това е нищо на фона на цялата конзола.
юни 17th, 2013 at 08:51
Трябва да сложите по едни слушалки за да няма ехо 🙂 , някой си беше надул колоните и въртеше звука много долно 🙂 . Колкото до химичните следи, не мисля че някакъв химикал може да оцелее след тампературата в реактивен двигател :). Забравихте да споменете ползването на captcha срещу директни атаки на сайта с джуркане на вариации или система за временен ban след няколко грешни пароли :). За бисквитите, както и да са направени , ако не е през https , тая информация може да се вземе и да се ползва успешно, без значение дали е хеш на паролата или случайно генерирано нещо. Ако трябва да е много секюрнато , добре е криптиран vpn тунел и https в него. Абе тая седмица с тия криптографии много болна тема ми ударихте 🙂 Слушах фо снощи до 2 часа и сега не помня всичко какво беше , ама като се сетя нещо пак ще пиша хяхяхя 🙂
юни 17th, 2013 at 08:57
А много ме дразнят chrome-тата като се ползва OpenSSL кво долно го дават задраскан , не е правилно туй . Какво като не са дадени едни пари там някой да го бил подписал , тинтири минтири ! И вече Уорнинг морнинг … А между другото на сайтовете на държавната администрация всичките са задраскани https 🙂 хяхя
юни 17th, 2013 at 09:29
@Жеко Жольов Копача ако имаш друг софтуер и решиш да участваш ще ползваме другия софтуер 🙂
Наистина се извиняваме за качеството на записа, все още се учим 🙂
юни 17th, 2013 at 09:46
gat3way ,не очаквах ,това което съм чел за него, е е че човек ,който се движи по сенките 🙂 и избягва да е център на внимание…
Приятна изненада,за мен лично е един от най-големите в световен мащаб в областта на криптографията,hashkill е пионер с някои от интегрираните си опции.Надявам се много по-често да го каните ,неизчерпаем източник на полезна информация е!
юни 17th, 2013 at 09:47
Принципно се разбрахме за още още едно участие, след като решим техническите проблеми 🙂 и си подберем по-смислени въпроси.
юни 17th, 2013 at 10:04
Mumble е с най нисък лаг от всичко дет осъществува. За геймъри е правено все пак 🙂 . Може да се ползва Push-To-Talk бутон или комбинация, хем да не товари канала като не се ползва, хем да няма шумове. Ама не е изключено като почне някой да приказва да заправя да нетисне копчетата, малко навик там трябва :). Иначе поддържа и отпушване на микрофона при определен товар и някой път се губят първите букви 🙂 , има си и варианта да е пуснат микрофона постоянно де . А да за всички OS- го има , на линуксите си го има и в пакетите, ама сървъра и клиента са отделно, па на уиндоуса са заедно в пак. На някои дистрибуции сървъра му се води murmur, на някои mumble-server , аа даа и поддържа SSL да не те подслушват противниковите отбори де си се каширал хах 🙂
юни 17th, 2013 at 10:37
Ами аз се извинявам, защото проблемите бяха почти изцяло от моя страна – техническите (ползвах скайп през Nexus 7, което става за втори или трети път и не очаквах тези номера с ехото и гъгненето, после на записа звучаха гадно). При мен пък звука нещо глъхнеше и трябваше да увелича звука, като увелича звука започват номерата с ехото и така. Другият момент е че от време на време в стаята влизаха в стаята жена ми и малката и се разбирахме на нещо подобно на езика на глухите, доста неприятни context switch-ове се получаваха. Следващият път трябва да си намеря по-спокойно място и най-важното – да не се пробвам да го правя през таблета.
Между другото, скайп клиента спря да respond-ва 2 пъти и трябваше да го трепя и пускам пак, не знам дали се чу каква тирада му теглих първия път и на него и на майките им, и на гугъл и на асус и на всички по веригата. За щастие го няма на записа, не знам само колко са се забавлявали Stilgar и gatakka 🙂
юни 17th, 2013 at 10:50
Еее вий па най интересното сте орязали 🙂 свобода на словото 🙂 не на цензурата хяхя 🙂
юни 17th, 2013 at 13:40
Интересно, че накрая на първата част, когато Stilgar каза за рептилите се чу един странен звук… това сауд ефект ли беше или просто глич?
юни 17th, 2013 at 13:41
Глич, който може да го ползваме за ефект за напред 🙂
юни 17th, 2013 at 14:38
Е стига де какво му е на постгрето.Mysql-а е много по-орязан.
юни 17th, 2013 at 15:43
Предложение за някои от следващите кастове: защо не направите тема за пострелационните бази данни или пък за функционалните езици които доста нашумяха за уеб разработка в последно време (lisp, scheme, haskell …).
Иначе интересен епизод, нека традицията за теория на конспирацията в края на епизода да се запази 🙂
юни 17th, 2013 at 15:46
Имаме подготвена тема за документните бази данни. Кога ще е не знам, ама я има в списъка 🙂
юни 17th, 2013 at 16:20
Между другото @gatakka има паста за зъби без флуор. В аптеките се продава паста „Билка“, която е без флуор и мога да кажа от личен опит, че е доста добра 🙂
юни 17th, 2013 at 16:46
ROFL, а аз си мислех, че тия забивания/умирания на приложенията стават само на китайските таблети, а то какво се оказа 😀
На мен и с приложението на Google ми е забивало така по време на конферентна видео връзка…
Много е гадно, но явно не са ги писали като хората тези приложения, защото като гледах ресурсите – нито процесора беше на 100%, нито RAM-та, нито дори интернет връзката (беше едва 20% от 54Mb/g стандарт).
юни 17th, 2013 at 17:33
За използването на няколко видеокарти за разбиване: то пак се слагат няколко, просто не се свързват и не се пускат в крос/сли режим, а се използват по отделно. ПЦ-то ги детектва като няколко и твоя си софтуер ги управлява.
Да обясня какво представлява крос/сли и ще ме разберете:
При игрите процесора изпраща към видеокартата буфер от команди за да може видеокартата да изчисли кадъра. Картата след това започва да изчислява и като е готова показва кадъра. От тук нататък може да започне да смята следващия команден буфер. Идеята в крос/сли е да не се чака картата да изчисли кадъра, ами ако има готов команден буфер за нов кадър, то той да се подаде на другата карта.
Общо взето се прави хардуерен мениджмънт на разпределение коя карта, какво прави. При кампют приложение, просто си го правиш сам.
юни 17th, 2013 at 18:02
Вие вече няколко подкаста направихте и все някога трябваше да има трудности.
Извода от Chemtrails новината – не се смейте на хората, че може да си купите xbox.
Ябълковия чушкопек, според мен е точно в стила на ейпъл – скъпо и тъпо. Според мен е тъпо, защото не може да си смениш процесор, дънната платка, видео картата, нито имаш възможностите при нормалните компютри като добавятне на втори, трети, четвръти твърд диск, добавятне на втора/трета видео карта или добавяне на компоненти. Целият този дизайн е просто един начин за да се ограничат възможностите на хората и ябълките го представят като чудо.
юни 17th, 2013 at 19:04
http://www.alienware.com/Landings/laptops.aspx ей тука 18-ката с 2Х видеокарти GTX 780Ms
with 4GB GDDR5 , Overclocked 4th Gen Intel® Core™ i7-4930MX
(8MB Cache, up to 4.3GHz w/ Turbo Boost) , 32GB Dual Channel DDR3L at 1600MHz . Само да махнат Windows-а от цената и ше се разберем , кви макове кви 5K$ 🙂
юни 17th, 2013 at 19:07
Това Google Loon много мяза на space dust.
юни 17th, 2013 at 19:48
gatakka , дай на тоя мейл дето съм го писал , някакъв мейл да ти пратя едно favico , ако го харесаш да го слагаш 🙂
юни 17th, 2013 at 19:52
Пратих ти го на тоя gmail-ския , ако не го ползваш пиши друг 🙂
юни 17th, 2013 at 20:09
Идеята на CrossfireX/SLI е горе-долу следната: драйверът представя за пред потребителя две или повече устройства като едно и за пред OpenGL, всичко е прозрачно. GLSL шейдъра се изпълнява върху двете устройства, като „разпределянето“ на workset-а се прави от драйвера, има няколко режима (AFR, SFR и т.н.). Шейдъра дращи върху някакъв общ буфер (съответно с времето и по-високите резолюции, PCIe bandwidth-а е започнал да става неадекватен и се е наложило да връзват допълнителни кабели). Всяка карта изпълнява част от nrange-a (opencl-ска терминология, не opengl-ска) и резултатът се „смесва“ композитно върху този споделен буфер, накрая този буфер се „визуализира“ от картата на която е вързан монитора. Съответно има разни хардуерни „хакове“ от страна на NVidia и AMD, профили и т.н.
При compute нещата, от това няма много смисъл. Нас не ни вълнува общият споделен изход. Сега чисто софтуерно, можем да работим по сходен начин – да вкараме няколко устройства в един контекст и една опашка и да изпълняваме един и същ kernel върху тях. Това звучи по-лесно, но парадоксално е толкова проблемно и създава такива проблеми, че на мен ми е далеч по-удобно да създам няколко хост нишки, всяка от тях да си има собствен контекст и собствена опашка, управляваща едно определено GPU. Проблемите са като почнем от концептуални (ако имаме „бързо“ и „бавно“ GPU на системата, скоростта се ограничава до скоростта на „бавното“ GPU и през част от времето „бързото“ ще стои idle вместо да върши работа). Отделно, и AMD и NVIDIA са се постарали да ти вгорчат живота с бъгливите си драйвери, кривата синхронизация, особено велик беше номера със синхронизацията със spinlock-ове, където при multi-GPU системи се радваш на 100% CPU load, защото някой идиот е решил че цикленето вместо спането е по-добра идея.
Мммм ако темата беше за GPGPU програмиране, щеше да има доста повече псувни.
юни 17th, 2013 at 20:25
Редакция: Писането на кирилица е задължително. Всяко едно устройство има кирилица! Няма оправдания и изключения!
юни 17th, 2013 at 21:13
След това изказване за кирилицата псирам да следя вашето предаване.. cya
юни 18th, 2013 at 01:42
Едва ли една среща с gat3way ще е достатъчна, следя му сайта и мисля че е internal IT psyho man. Общо взето всичко беше интересно, но може би от практична гледна точка е добре да се чуе от човек, който наистина разбира нещата кое от това, което се ползва ежедневно работи и кое не. Примерно това, че има некои ударени с теслата, които могат да разбират от delay-я, който прави сървъра някакви особености на криптирането (дължина, сложност на паролата и т.н) е интересно, но пък нещата от ежедневието, които обясни md5, sha1 и сравнението с bcrypt ми бяха по-ценни. Да, то може и да се прочете, но в две изречения и ясно казано едва ли. Често обяснявам на приятели, че при компютрите е като при всяка сигурност – това, че си слагаш охрана не те прави неубиваем, а просто кача цената на убийството. Проблема иде от шума в целия Нет и разногласията по отношение на някои практики, един каже https е толкова сигурно като да пратиш писмо по пощата, друг нещо друго, та е добре да се знае цената на всяко нещо като цена на охрана. Това струва толкова има предимства, има недостатъци. Така ще знаят разработчиците в зависимост от това дали правят сладкарница или бижутерен магазин, колко охрана да сложат, че да не си струва убийството. Или просто ми се иска да е по-просто, а то не е.
юни 18th, 2013 at 08:43
Ама чакайте бе хора , кой хеш по сигурен. То ако са ти събрали хешовете, значи че базата данни ти е пробита, от там нататък какво повече ?!
юни 18th, 2013 at 08:53
http://crackstation.net/hashing-security.htm
юни 18th, 2013 at 09:17
Ми дай да ръгаме plain text пароли тогава щом от там нататък няма какво повече 🙂
юни 18th, 2013 at 09:32
Е то като пробиеш базата за какво са ти пароли от там нататък 🙂
юни 18th, 2013 at 09:34
По принцип сигурността включва три неща – условно „превенция“, „откриване“ и „реакция“. При липсата на едно от тях, цялата идея се обезсмисля. Подобряването на хеш алгоритъма е мярка свързана предимно с „превенцията“. Всичко това единствено ти купува време, но няма как да елиминира проблема. В случая с магазина, може да направим една асоциация с касата където пазим оборота – в зависимост от това колко е сигурна и с колко дебели стени, толкова повече време ще отнеме на крадците да я разбият. Но ако няма аларми, които да ги засекат и няма хора, които да реагират на алармата, няма значение колко ще е сигурен сейфа.
Без значение колко усилия се хвърлят върху създаването на по-сигурни приложения, според мен е невъзможно да се гарантира че няма да стане някаква издънка и базата с потребителите да се окаже в лошите ръце. Така че сигурността започва оттам, но ако няма някакви средства такива неща да се засичат (IDS-и или примерно при leak-ване на базата, това би могло да се засече като аномалия в изходящия трафик) и ако няма хора, които да реагират на такива аномалии, тогава всичко е доста безсмислено.
Та в този ред на мисли, виждал съм една забавна идея. В базата нарочно се вмъкват „фалшиви“ акаунти с „лесна“ парола. В момента в който някой се опита да се логне с някой от тези „фалшиви“ акаунти, най-вероятно базата е компрометирана и следва да се вземат мерки. Когато за пръв път видях това, ми се видя малко глупава идея, но колкото повече мисля за това, толкова повече стигам до извода че е доста хитро хрумване.
Съвсем в друга посока съм виждал друга идея – ползват се две salt стойности – едната е „публична“ и уникална за всяка парола и в базата. Другата е „тайна“, не се пази в базата, обикновено една и съща за всички пароли, хардкодната някъде в кода примерно. Сега това не е супер гениална идея, защото приема че лошите няма да се сдобият с достъп до кода. Но дори без такъв, ако „тайния“ salt е къс и лесно „разбиваем“ то не е голям проблем да си регистрираш акаунт с известна парола, да видиш в базата публичния salt и да атакуваш оттам „тайния“ salt.
юни 18th, 2013 at 09:34
Ако разбиеш базата и паролите са криптирани, какво прави „лошия“ с тази информация?
Основния хак по тия бази е за да се вземат точно тези данни, имена, мейли, кредитни карти и ПАРОЛИ, понеже хората масово ползват една парола за много системи.
юни 18th, 2013 at 09:48
Всяка leak-ната база означава по-ефективно трошене на следващата. Обогатява речниците, разкрива някой друг pattern при избора на пароли. Има различни софтуери за анализиране на списъци с пароли (примерно pipal), които автоматизират донякъде процеса. Всичко това води до по-добри правила и по-богати входни речници.
Сега примерно „модерни“ са трансформациите свързани с Damerau-Levenshtein distance – вземаме входните низове, генерираме всички кандидати с Damerau-Levenshtein разстояние до 3 примерно. Така примерно ако имаме във входното множество „ivancho“, ще генерираме кандидати от сорта на „iv@ncho77“.
юни 18th, 2013 at 10:02
Абе най добре е да не се стига до там да ти вземат базата 🙂 . Може да се криптира всичката важна информация в базата преди записа, ама тогава търсенето в базата по криптираните елементи отпада 🙂
юни 18th, 2013 at 10:05
А къде ще държиш ключа за тва криптиране? Изтичането на базата не е краят на света. Имал си дупка запушваш я, връщаш backup да оправиш поразиите и продължаваш. Ако leak-неш на хората паролите в plain text обаче нещата миришат…
юни 18th, 2013 at 10:12
Ключа на много места можеш да го държиш, най вероятно ще е в директория не достъпна от уеб сървъра. И друг въпрос, ако си напишеш собствена кодираща система за паролите (не криптираща , кодираща) и която никой няма да знае на какъв принцип работи освен тебе, не усложнява ли значително процеса по разкодирането ?
юни 18th, 2013 at 10:26
А и една друга простотия ми дойде на ума 🙂 , паролите да не са въобще в тая база данни а да се сверяват с едно външно приложение което да ползва sqlite3 с 2 таблици user и pass и да връща само true, false 🙂
юни 18th, 2013 at 10:38
@thedem –
Според мен не е така. Атаката може да скалира и да се пренесе по други сайтове или дори по цялата система, а хеширането може да забави това и да даде ценно време или да накара ‘лошите’ да действат под натиск и да оцапат работата. При една от атаките в сайта на Apache беше използван мисля дори обикновен xss бъг в тяхната jira система. След като се докопаха до криптираните пароли „лошите“ решиха да пращат имейли за смяна на паролата, което вече е въпрос на време да бъдат усетени, обаче пък за сметка на това намериха sudoer, който ползва една и съща парола за Jira системата и главния сървър. Ако се бяха се добрали до репозиторито и бяха го сменили с някое леко бъгната тяхна версия, както и ако бяха провели атаката по-внимателно можеше белята да е огромна. В случая хеширането все пак играе някаква роля, с което притиска ‘лошите’ да действат по начин, при който ще бъдат усетени.
Според мен цялата работа с паролите е слабостта на човешкото мислене. Просто за нас хората трябва да има логика, така помним просто, а има ли логика има и алгоритъм. Още повече, че можем да помним ограничен брой пароли.
юни 18th, 2013 at 10:46
@thedem – а и от наша гледна точка може базата данни да е всичко, но от потребителска да не е. Може на потребителя да не му пука, че са влезли в нашата баничарница в която и той е клиент, но да му пука, ако влезнат и в бижутерския магазанин, в който пазари.
юни 18th, 2013 at 10:52
Ами на клиента като му пука за друго място , да си ползва друга парола за там 🙂 , като не помни да записва, или да каже на браузъра да му я запише 🙂 то като ползва една парола навсякъде сам си се е хакнал, няма за какво да го хакват повече . Каквото и да го правиш тогава не можеш да го спасиш. Ше му пратят на пощата някакво привлекателно предложение в което да се регистрира пак със същата парола и ше му го сложат 8 ката 🙂
юни 18th, 2013 at 10:56
То затова по защитените работи ползват електронен подпис , пин код и други. Някои онлайн игри ползвт за набиране на пинкода табло с цифри които всеки път са рандъм разбъркани да не се хванат кординати на мишката с троянец и се цъкат само с мишката , да не се хванат с кейлогър, и пина няма как да ти е същия щото ти го генерират от там.
юни 18th, 2013 at 11:50
Най-сетне!
От толкова време чаках да коментирате тази тема.
gat3way е уникален специалист, много, много навътре с материята на криптографията, Linux и low-level нещата, един от най-добрите в нашата мила родина бих казал.
Не го познавам лично, но това са ми впечатленията от прочетеното от сайтът му и форумите, където участва.
Нямам търпение да се прибера от работа, и да го изслушам, че тук нямам звук.
юни 18th, 2013 at 12:08
Няма да чуеш много повече мънкане и шум за което се извинявам, ще се постарая повече другия път.
И далеч не съм от най-най-добрите и тем подобни.
юни 18th, 2013 at 14:00
Това с патента за пренос на информация през тялото е странно, защото преди няколко месеца Microchip анонсираха същата технология, категоризирайки я като Embedded Security: http://www.microchip.com/pagehandler/en_us/technology/embeddedsecurity
юни 18th, 2013 at 14:08
Интересно ми е какво е мнението ти (GW) по отношение на този talk-презентация на тема: Certificate Authority Collapse [29c3]
Това не знам дали все още е в сила, но все пак те кара да се замислиш, до къде могат да стигнат определени корпорации, за да си запазят бизнеса и паричките 🙂
юни 18th, 2013 at 15:04
Браво момчета, страхотен ви е подкаста. Дано да ви тръгне, че да продължите да го правите ежеседмично.
юни 18th, 2013 at 15:15
Абе и 2 пъти седмично да го правите няма да е лошо 🙂
юни 19th, 2013 at 02:50
Планове за високо летящи балони които да вършат нещо има от много отдавна.
Доколкото знам, един от първите опити да се използват е през ВСВ. Нямайки възможност да бомбардират САЩ, японците пускат хиляди хартиени балони с вързана за тях бомба. От тях само една пада в САЩ.
Най важното е, че балона е неуправляем по оста ляво дясно и напред назад. А като няма и човек на борда става неуправляем и нагоре надоло. Тази идея, с неуправляеми балони да покриваш територия… извинявам се, но е технически неиздържана. Балоните ще са напълно неуправляеми и ще летят където и както си искат.
юни 19th, 2013 at 09:15
@Селянин това което казваш е вярно, но те явно са намерили начин да ги контролират по някакъв начин.Не разбрах точните технически решения как го правят, но не им е нужна голяма точност, понеже идеята е да хвърлиш доста балони на горе-долу еднакво разстояние. Приемника на земята не му пука към кой точно балон ще се закачи, понеже ако са много балони ще направят grid, който ще води до някоя наземна станция.
юни 19th, 2013 at 09:57
Нямаше ли да е по лесно да измислят някакви кули с насочени лазери за оптична връзка 🙂
юни 19th, 2013 at 10:08
А , то даже имало измислена технология от преди няколко години https://www.youtube.com/watch?v=Vi5jnExnjxA
юни 19th, 2013 at 11:55
Ааа сетих се да питам, какво е мнението на gat3way за OTR (Off-The-Record) криптиращата благинка за Instant Messenfer-ите ?
юни 19th, 2013 at 12:37
При следващото гостуване на gat3way може да разгледате темата за псевдо-рандом генераторите (напр. rand, mt_rand в PHP, etc…) и тяхното място в сигурността, начини за компрометирането им, и така нататък.
юни 19th, 2013 at 13:26
Също малко по-подробно за Rainbow таблиците може да поговорите (по-специално когато се опре до използването им за кракване на MD5 хеш), по възможност да се обяснят основите като цяло, идеята и приложението им на по-разбираем за незапознатите с тях език. 🙂
юни 19th, 2013 at 14:02
По въпросите:
По отношение на EU регулациите на CA-тата, това е по-скоро политически, отколкото технически проблем. Няма как да имам обосновано мнение, но вътрешното ми усещане е че става по-скоро въпрос за бюрократичен тъпизъм, отколкото за лобистки интереси. Случай като този с Diginotar ще съсипе репутацията еднакво добре и на малка и на голяма компания. От друга страна там има назначени хора, които трябва да си оправдават заплатите, измисляйки всякакви безумни регулации в името на доброто на ЕС и ето че вършат работа.
Що се отнася до OTR, нямам ясно мнение, понеже не ми се е налагало да се запознавам в детайли. Има един „вграден“ проблем с автентикацията, поне когато за пръв път установяваш контакт, който налага наличието на „споделена тайна“ или наличието на друг, сигурен канал на комуникация. Донякъде изискването за сигурния канал отпада с последната ревизия на протокола, където ползват някакъв zero-knowledge протокол (SMP?) и което донякъде подобрява нещата, въпреки че според мен просто го прави по-лесен от потребителска гледна точка за сметка на въвеждане на друг тип рискове (не-технически). Като изключим това, мисля че е добра идея и има разни хубави качества (например perfect forward secrecy).
С PRNG проблемите, нещата също са забавни, предвид това че по много неочаквани начини могат да доведат до много големи поразии, с уеб приложенията примерно това е добре изразено. Там забавното е че разработчиците на приложението дори да се постараят, не може да знаят какво друго уеб приложение върви на същият сървър, ползва същите PRNG функции и в рамките на една keep-alive HTTP връзка нещата могат да се комбинират по забавен начин, така че примерно да „познаеш“ някоя captcha или новогенерирана парола при password reset.
Що се отнася до rainbow таблиците, не знам дали бих могъл да обясня добре за какво става въпрос, без да драскам някъде. Лекторските ми способности въобще не са на добро ниво 🙂 но и специално rainbow таблиците като идея трудно се възприемат без да нарисуваш няколко вериги и да демонстрираш търсене в тях стъпка по стъпка – с пресмятането на новия низ с редукционната функция, хеширането й , сравнението на крайните хеш стойности и какво правим при съвпадение, както и какво става като имаме колизии и защо е важно да ползваме различна редукционна функция за всяка „брънка“ от веригата. Ако виждаш нагледно какво се случва, цялата идея се осмисля доста по-лесно и бързо. Но мога да се пробвам да го обясня, не гарантирам особен успех обаче 🙂
юни 19th, 2013 at 15:00
Ако се разграничим от podcat-а, то ще е супер (при желание от твоя страна естествено) да направиш едно видео уроче с обяснение за Rainbow таблиците. Така хем ще можеш да покажеш, хем ще имаш възможността да говориш и да го обясниш. 🙂
юни 19th, 2013 at 20:35
Извън темата!: Искам само да отбележа, че (на базата на моя личен опит) nerds2nerds.com се държи осезаемо по-добре под IE…
юни 19th, 2013 at 23:18
Е вие сте се събрали. Сега попаднах на подкастовете в блога на Иван, че и @gat3way се е включил. Поздрави за начинанието и много успехи 🙂
юни 20th, 2013 at 20:31
Здравейте искам да попитам правилно ли съм разбрал, че трябва да се използва различна „сол“ за всеки потребител и чисто и просто как ще се имплементира това? На базата на част от неговото потребителско име или ? Ето как е даден пример в книгата „PHP Cookbook – O’Reilly“, в които „солта“ е констранта.
http://pastebin.com/WqGVKA75
юни 20th, 2013 at 21:04
Само на мен ли ми направи впечатление, че аудиотата не могат да се seek-ват. Пробвах с Chrome и Firefox. При опит да сваля директно файловете – пак не става. Моля, оправете го.
юни 20th, 2013 at 21:40
Да, най-сигурно е разбира се да е различна за всеки потребител, и да се определя в момента на регистрацията му.
За това от какво да се състои – може да е от всичко, което горе-долу е надеждно за случая.
Потребителско име, криптирана и форматирана по някакъв начин парола, част от нея (криптната и изрязана), или пък ако щеш една моя идея – използвай random.org за да взимаш от API-то случайни числа в някакъв диапазон, и за тези числа с char() в PHP определяй някакъв случаен символ от ASCII таблицата, и така да речем в един for цикъл си вадиш 100 случайни символа от които вадиш сол на кристали. 😀
Ето ти примерна функция, тук е с PRNG ( mt_rand(); ), но си го сменяш с числа от random.org (file_get_contents(„api_url“);) :
http://pastebin.com/H9H8QmHq
А, като казах random.org – да попитам Милен (@gat3way) ако още чете, какво мисли като цяло за концепцията на този сайт, и според него числата, генерирани на базата на звук от атмосферата (бял шум, в случая сайта използва радиоприемници разположени из различни точки на света, и настроени между две станции, като в резултат се генерира бял шул на базата на който се извлича с алгоритъм 1 или 0 и се съставя сийд за рандом генератор – повече инфо – http://www.random.org/history/) напълно случайни ли са и стават ли за използване в сферата на криптографията и сигурността?
юни 20th, 2013 at 22:42
MD5 на timestamp-a на регистрацията , нали се записва почти винаги кой кога се е регбал
юни 21st, 2013 at 00:08
Аз не бих си мандахерцал случайните числа из Нетя. Те са си доста чувствителна информация.
@Denis – Има много начини за генериране на случайни низове/числа, просто порови и ще намериш.
Интересното ще дойде в логина, когато ще трябва освен паролата да вземеш и солта и да възпроизведеш същия алгоритъм като при регистрацията примерно, ако при регистрацията си възпроизвел парола от рода sha1(salt . password) /*говорим за пхп контекст*/ после когато сверяваш при логина ще трябва да сравниш дали sha1(salt . password) ще е равно на това, което имаш като парола в базата данни. Не е кой знае какво като сложност, но както обикновено е галимация. Може да си сложиш и статичен salt, но според мен няма да има смисъл да го държиш в базата (ако и двата са в базата ми се вижда не ефективно), по-добре е да е в някой конфиг файл или дори хардкоднат някъде като променлива. Обърни внимание, че в подкаста става въпрос и за дължината на salt-а.
Поздрави
юни 21st, 2013 at 01:12
Добре де но не разбирам като генерирам случаен низ при регистрацията после как да генерирам при логина същия ? Разбира се изключено е да го държа тоя низ в базата.
юни 21st, 2013 at 01:18
Извинявам се за двойния пост, но ми хрумна нещо солта може ли да е нещо от сорта на: низ с дългжина потребителското име – 2 знака ?
юни 21st, 2013 at 01:21
Запази си го в таблицата в която пазиш хеша.
Иначе с Firefox има някви проблеми ама не съм сигурен кога се случват. Нещо дава loading от време на време и през това време не може да се seek-ва. Пробвай да ги play-ваш от блогпоста, а не от frontpage-а щото май става няква мизерия като има твърде много player-и. С IE и Opera ми seek-ват пушка.
юни 21st, 2013 at 09:11
Надрасках тая схема с външния контейнер за съхранения на паролите на питоня 🙂 . Aко някой иска да ги държи на друго по сигурно място :).
Eй от тука можете да я дръпнете http://dox.bg/files/dw?a=87ce3e7768 , кой както иска да си я подобрява и ъпгрейдва , променя, копира, споделя, лиценз free-for-all 🙂 някой ако не го мързи може и на C да я надраска 🙂 . Ще се радвам да си кажете и мнението, дали ви харесва или тц 🙂
юни 21st, 2013 at 09:24
@Denis – Ако правиш статичен salt, който ще е някъде в кода, няма как да генерираш при регистрация случайно число/низ. Точно за това ще имаш този salt в кода, за да можеш да възпроизведеш чрез него алгоритъм за парола при регистрацията и после същия алгоритъм за логин.
Ако правиш за всеки потребител salt, то тогава няма как ще трябва да записваш някъде salta и най-доброто място за това е базата данни. Тогава можеш да генерираш при регистрацията случайно число/низ защото то ще бъде записано в базата. Примерно да кажем случайното число низ което сме генерирали е 112 , а паролата на потребителя е „ostavkaNaPrestypnicite“. Алгоритъма с който ще правиш хеш за базата е да кажем sha1( 112 . ‘ostavkaNaPrestypnicite’) . Сега ще запишем този резултат като парола в базата, а ще запишем и 112 също, защото то е случайно число и при следващия потребител може и най-вероятно ще е друго. Като се логва потребителя вземаме записа от паролата и вземаме числото 112 от базата, отделно имаме това което потребителя е дал като вход за парола, което ще бъде променливата $pass_in. Сега проверяваш дали sha1(112. $pass_in) е равно на стойността от парола в базата данни. Ако потребителя е въвел ‘ostavkaNaPrestypnicite’ като парола, това ще е така и логина ще е успешен.
Най-добре е да намериш някакъв код първо да видиш salt, който е в кода и такъв който е различен за всеки потребител. После да направиш двата поотделно и най-накрая да направиш микс от двата. Но без да погледнеш мисля, че ще ти е доста трудно. Моя съвет е да потърсиш код.
юни 21st, 2013 at 10:26
salt в кода рязко намалява смисъла от salt както се каза и в подкаста. Ако имаш 1000 потребителя е 1000 пъти по-полезно да имаш отделен salt отколкото salt в кода.Ако имаш милион потребителя е ма практика задължително да имаш различен salt.
юни 21st, 2013 at 11:26
Значи не е проблем, ако солта се записва в базата данни в таблицата с потребителите или в друга таблица с външен ключ към таблицата с потребителите ?
в статията http://phpmaster.com/password-hashing-in-php/ са показани сходни методи
юни 21st, 2013 at 12:14
Вижте сега, когато му казвате случайни числа, какво всъщност имате в предвид? Как да ги вземе? Кои са тези много начини за генериране на случайни числа?
Варианта да използва PRNG (rand, mt_rand в PHP for example или който и да е било друг PRNG от друг език) автоматически напълно и без колебания отпада, щом се касае за сигурност. Ето защо – http://www.gat3way.eu/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=99&cntnt01returnid=55.
Какви са другите начини да се вземат случайни числа, освен random.org ?
За опасността да се взимат числата от нета, специално за random.org не важи. Не се съхраняват по никакъв начин на сървъра и се взимат от буфер, който през няколко секунди се обновява.
А ако толкова се страхувате – random.org поддържа SSL. Ето например стандартното им API за взимане на числа през HTTPS – https://www.random.org/integers/?num=1&min=1&max=100&col=1&base=10&format=plain&rnd=new .
Проблеми няма, а и е възможно най-надеждният източник на произволности с висока ентропия предвид, че се взимат на базата на white noise (пуснах по-горе линк).
Идеални са числата за сол, а и има други опции за генериране, освен на числа.
юни 21st, 2013 at 12:43
Е на всеки потребител ще влизаш да ги генерираш там ръчно ли , или с cURL 🙂
юни 21st, 2013 at 12:56
API-то връща plain/text резултат.
Може да си ги вземеш с file(); в масив и да си работиш с произволните (за едно число с file_get_contents(); примерно) числа.
Само ако ползваш SSL – разрешаваш го в php.ini, защото иначе и двете функции не искат да взимат числа.
А и както казах – няма нужда от притеснения за сигурността, щом се работи с random.org.
юни 21st, 2013 at 13:12
Който смята, че има някаква опасност да се взимат случайни числа за salt като се създава/сменя паролата на потребителя явно няма идея за какво точно служи salt-а. И да ти познаят salt-а к’во от т’ва? Него без туй го пише в базата директно да не говорим, че атакуващия ще види зор да познае random числото точно когато определен потребител си е сменял паролата преди 6 месеца.
юни 21st, 2013 at 14:11
Едно интересно четиво по темата за криптирането и подправките:
http://www.download.bg/index.php?cls=forum&mtd=thread&t=286174&p=2#post286247
юни 21st, 2013 at 14:54
@programings – Аз лично не се вдъхновявам от идеята да се осланям на други услуги/сървиси особено що се отнася за сигурност. Може и да е сигурно в случая, но аз лично не харесвам идеята данни влияещи пряко на моята сигурност да идват от място, което приемам за сигурно на юнашко доверие. Не ме разбирай погрешно, то може и да е много сигурно, но моя принципа по който ще се старая да правя нещата е друг. Ще искам да ограничавам циркулирането на информацията и досега ѝ с услуги и служители. За мен ползването на външна услуга, която да влияе на най-чувствителните данни в базата ми не е оправдано просто защото всяка външна услуга е приемането нещо на чисто доверие, а това за мен не е най-добрия навик , който да възпитавам.
Още повече, че трябва да мисля за транспортирането на данните. Колкото и да е сигурно ми се струва не е съвсем…. Понякога криптирането на информацията не е достатъчно тя да бъде опазена и в цялост. Понякога за да бъдем засегнати е достатъчно знанието на врага, че тя съществува. В контекста на подкаста да си представим следния сценарии : нашия сървър (Н) взема от сървъра на рандом (Р) определената информация в определените от приложението моменти. Но между двете седи лошия (Л) и слухти. Той не може да разкриптира информацията, но знае че между Н и Р има трафик, вероятно знае в кои часове, дни и месеци този трафик се засилва. Ако е някой психо може би ще установи и кога този трафик е за една част на приложението и кога за друга. Примерно си прави регистрация в ниско натоварен часови пояс и отчита какво е изслухтял в това време. После повтаря опита 5000 пъти за един месец. Може и да успее да разбере кога трафика е за регистрация и кога за нещо друго, може и да не успее да бъде разобличен по броя регистрации. Сега си представи, че Л реши да прави многофлангова атака (раишли! може би по-правилно е да се каже друг вектор на атаката 😉 ) и запоне да провежда черна PR кампания срещу Н . От трафика между Н и Р може и да успее да си състави добър репорт за качеството на PR кампанията си и да наблегне на страните в тази кампания, които намаляват този трафик, сиреч по-малко регистрации по-малко успешen черен PR.
Ако въпроса със случайните числа е чак толкова наболял за сигурността в даден случай, а на мен ми се чини че ще има доста-доста неща да си оправя преди него, може би е добре да се наблегне на обучение на нас или някой от хората с които работим. В статията, която даваш gat3way е намекнал, че urandom е все пак по-добър вариант от rand() функцията на php.
Честно да си призная надали някога ще стигна до такива секюрити висоти, че да мисля за автентичността на случайните числа, от които ще генерирам пароли. А и нещата, които правя надали ще са обект на такива психопати. С тях за сега не сме на една планета.
юни 21st, 2013 at 15:02
Добре, но изниква един въпрос – кой е L и къде точно по веригата на предаването на пакетите от H до R слухти?
Ако пуснеш един traceroute до random.org ще видиш (естествено), че пакетите заминават от твоя компютър H, минават през различните маршрутизатори на ISP-то ти (през всичките level-и), и достигат до R.
Тук значи варианта е трафика ти да се снифва от ISP-то или някой системен администратор, обслужващ някой крайпътен level маршрутизатор от веригата.
В интерес на истината според теб тези хора каква работа имат да следят какви числа ти взимаш, и да правят тъмни и зли PR кампании?
юни 21st, 2013 at 15:09
Това разбира се говорим в условията на ползване на услугите на random.org в някаква мрежа, която е под твой контрол, и в случаи, че сървъра H си е твой.
Иначе в чужда мрежа – риск има.
юни 21st, 2013 at 15:34
@programings – Да, затова е добре да имаме цената на проекта пред себе си. Няма смисъл да пазим обикновена баничарница с бронирани стени и да направим стените на трезора от гипсокартон. Аз имам предвид проект, в който автентичността на случайните числа е от голямо значение, а това предполага наистина много много високо ниво на сигурност, а съответно и голяма цена на проекта.
Работата на системния администратор не винаги включва това да пази некомпрометирана машината си, напротив понякога може учтиво да помогне тя да се компрометира – от глуспост или примерно нужда от $. В проект при който сме опряли до автентичността на случайните числа това ми се вижда правдоподобно.
Може да словоблудстваме още, но аз се изчерпах…. и Боже прости, но ми олекна. Ох!.
юни 21st, 2013 at 16:01
Само искам да поясня, че /dev/urandom е достатъчно добър източник на случайни числа за 99.9% от случаите. Грубо казано, може да приемем че /dev/urandom е криптографски-сигурен PRNG ( http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator ), който се seed-ва от entropy pool-а на ядрото (достъпен през /dev/random).
/dev/urandom би бил несигурен ако се окаже че PRNG алгоритъма зад него се окаже „пробит“ – т.е открие се някаква слабост (статистическа – bias, къс период – или друга, примерно начин да се познаят старите стойности на база на текущото състояние на алгоритъма или нещо от сорта), което засега не е факт. Поради тази причина притесненията са свързани предимно с критична PKI инфраструктура (примерно root CA частен ключ генериран на база на /dev/urandom), за която би излезнало „солено“ проблемът да се отстрани.
Ако става въпрос за генериране на временни пароли, captcha низове и тем подобни неща, мисля че /dev/urandom върши доста добра работа.
юни 21st, 2013 at 16:37
А каква е разликата м-у /dev/random и urandom ?
юни 21st, 2013 at 16:39
Да, естествено, че върши работа, но примерно в PHP скрипт не е приложим. Защо?
На външен хостинг никой няма да ни позволи да изпълняваме команди върху сървъра.
А ако сме си на наша машина е приложимо, но отнема системно време докато се изпълни командата все пак.
Така че: плюсове: сигурен източник, минуси: бавен за използване в PHP.
юни 21st, 2013 at 19:16
od -vAn -N4 -tu4 < /dev/urandom
od -An -N2 -i /dev/random
Защо да е бавно за PHP , PHP-то взема готов резултат със shell_exec а туй работи бързо 🙂 "C" e .
юни 21st, 2013 at 19:18
А даже и да е бавно го ползваш веднъж на регистрация.
юни 21st, 2013 at 20:17
Дъдем ето нещо за теб:
https://www.system76.com/laptops/model/galu1
юни 21st, 2013 at 20:53
Пак повтарям дали ще ви познаят случайното число от което сте генерирали salt няма НИКАКВО значение. Ако не може да разберете защо няма значение то поне обърнете внимание, че salt-ът обикновено се държи при хеш-a. Тоест, който има хеш ще има и salt.
юни 21st, 2013 at 21:22
@thedem, логично нов salt трябва да се генерира и при смяна на паролата. Ами ако някой тръгне да си сменя паролата през 1 секунда, разбрал, че използваме /dev/random, и правещ процедурата с цел да ни DDoS-ва, и то забележи локално – още по-опасен DDoS. 🙂
юни 21st, 2013 at 21:26
Представи си, че сървъра ни е домашен (казах, че на външен хост не е приложимо по никакъв начин) със слаби параметри (много хора правят старите си компютри на сървъри, и държат малки сайтове на тях), и някой тръгне през 1 секунда да си сменя паролата, и ти взимаш от /dev/(u)random. Нали се сещаш какво ще и се случи на машинката. Нито shell_exec ще те спаси, нито нищо.
юни 22nd, 2013 at 00:12
Поздрави за добрия подкаст, особено тази тема с криптото е супер, а и gat3way е големец там.
юни 22nd, 2013 at 00:18
@Жеко Жольов Копача, Intel GPU SUCK
@programings , спри се вече щи прегрее CPU-то 🙂 ,
Наздраве !!!
юни 22nd, 2013 at 02:21
Няма нужда да се изпълняват команди върху сървъра, от device node-а се чете по същият начин, по който се чете от файл. Що се отнася до хостинга, проблем биха били по-скоро open_basedir ограничения или chroot-нат apache примерно.
shell_exec() въобще не работи бързо и това е без значение дали е реализирано на C или не. Това което прави е да форк-не един bash процес, който съответно форква командата, входа/изхода минава през pipe-ове и всичко това е огромно разхищение на процесорно време и памет. Просто четенето от файла е далеч по-бързо.
Разликата между random и urandom е че първото е entropy pool-а на ядрото, който се пълни от разни случайни събития (хардуерни прекъсвания) и е ограничен. Четенето оттам block-ва ако pool-а е празен докато не се случат нови събития за да може ядрото да достави следващите случайни стойности. urandom просто ползва малка част от същия pool за да seed-не някакъв алгоритъм и връща стойности далеч по-бързо (и не блоква съответно).
Викането на външна команда чрез shell_exec() и четенето от /dev/random са доста лесен начин да позволите да ви DoS-нат, първото защото като форкнеш дори няколкостотин bash процеса, дори бърза машинка ще се сгъне приятно, а второто, защото като се изчерпа pool-а, заявката ще чака и така относително бързо ще „заемеш“ всичките worker-и на уеб сървъра да чакат нещо да се случи и да не може да се accept()-ват нови клиентски сокети.
А иначе Stilgar е прав че няма никакво значение как се генерират salt стойностите, стига да не се повтарят. Можеш да ползваш дори потребителското име за целта, някои уеб приложения го правят. Въпреки че според мен е лоша идея предвид че администраторското потребителско име е едно и също за всяка инсталация и това позволява изготвяне на rainbow таблици специално за целта.
юни 22nd, 2013 at 08:54
Гейт, ако те разбирам правилно, можем да тръгнем от някаква стойност достатъчно голяма, да речем няколко милиона и при всяка нова парола да качваме стойността с единичка? Това ми се струва най-бързо като направа. Като числото ни е дълго отговаря и на условието нали? Или трябва да са съвсем случайни знаци, не става само с числа?
юни 22nd, 2013 at 09:10
Няма да те DoS-нат , като напраска повече заявки от колкото трябва за количество време, мандалото лопва и един ред в htaccess / deny from се добавя автоматично 🙂
юни 22nd, 2013 at 09:50
Само дето това няма да те спаси да ти напълнят канала и доставчика ти той лично да те резне, с което лошите пак печелят.
юни 22nd, 2013 at 09:51
Е то за DDoS спасение няма 🙂
юни 22nd, 2013 at 10:44
За какво си говорим хяхяхяхя 🙂 http://www.vesti.bg/index.phtml?tid=40&oid=5871191
юни 22nd, 2013 at 10:51
@Жеко Кольов Копача – тогава ще трябва да пазиш някъде текущата стойност – или в база или във файл да речем.
Лесно и бързо можеш да го генерираш на база timestamp – примерно с microtime(). Ако искаш да е по-дълъг може да го конкатенираш с потребителското име.
юни 22nd, 2013 at 12:59
Двамата сте много добра комбинация, на моменти мненията Ви се разминават, получавасе дискусия по някоя тема и се получава наистина много интересно, благодаря че отделяте време и го правите заради нас.
Като идея за следваща тема, може да поканите някои system или network admin за да дискутирате IT сектора в българия, какви са перспективите в различните сфрети и има ли перспектива за IT в България.Общо взето да споделите личен опит за тези които още не са се ориентирали на къде точно да се насочат.
юни 22nd, 2013 at 14:24
Да не забравите за новините филтрирането за букмейкърските сайтове. 🙂 Не че ми дреме за тия сайтове , ама е грубо тъй да се филтрира. Да карат хората да ползват проксита и VPN и кво ли не 🙂
юни 22nd, 2013 at 16:14
Искам да доживея деня, в който на Американците ще им филтрират и чистия въздух – тогава Хитлер ще се обърне в гроба от щастие 🙂
юни 22nd, 2013 at 16:19
Който се интересува от криптография може да погледне онлайн курса (започнал е на 17ти юни) Cryptography I:
https://www.coursera.org/course/crypto
Курса не е елементарен и ако искате да го изкарате трябва да сте добре с английския и математиката и да можете да отделяте поне 7 часа седмично за него, но може и само да го погледнете за да видите за какво става дума.
юни 22nd, 2013 at 16:45
То ответния удар не закъсня де. Резнаха предаването на рали 24 Le Mans за българия :). Ся като резнат всички спортове за тука , да ги видя българските букмейкъри за кво ше зимат залози. Иначе който е фен на ралито http://lemanslive.com/
юни 22nd, 2013 at 18:08
Мерси за курса, тъкмо се чудех за нещо такова и търсех повече информация, това е един перфектен начин да попълня пропуските 🙂 Че даже е в две части.
юни 22nd, 2013 at 18:45
Имам въпрос относно md5 и паролите. Вместо „осоляването“ md5(salt . password), може ли да се използва маскиране(побитово бинарно И)? Другият вариант, за който се сещам е да се раздели самата парола на модули, да се извършат разни неща с тези модули/парчета и след това да се прави md5 на цялата съвкупност?
юни 22nd, 2013 at 20:52
Всичко може , няма ограничение, важното е на тебе да ти харесва , и евентуално някой ако ти плаща за това дето правиш и на него да му харесва 🙂
юни 22nd, 2013 at 21:27
Zennin, много хубав въпрос, на който вероятно ще чуеш различни отговори. Според мен, в повечето случаи, „смесването“ е по-лоша идея. Би било добра идея ако salt-а е дълъг, генериран без bias (т.е примерно не се състои само от долните 128 символа в ASCII таблицата така че старшия бит е винаги 0) и не се AND-ва, а XOR-ва.
Къде биха били евентуалните проблеми? Ако salt стойността е къса, то бихме могли да приложим bruteforce атака за късите пароли, където печелим, защото няма да има нужда да смятаме хеш стойностите за всеки възможен salt на кандидат-парола. Ако „познаем“, тогава за да получим паролата, трябва да приложим съответната побитова операция с известната salt стойност. Това е валидно разбира се и при конкатениране на salt-а, но там сравнително бързо губим това предимство (достатъчно е salt-а да е само 5-6 байта дълъг, за да обезсмисли това упражнение, освен за много къси пароли).
Допълнително, мисля, че смесването трябва да се прави с XOR, а не с AND. Причината е че при AND-ването губиш ентропия – който и от двата бита да е нула, получаваш нула, единствено ако двете са единици получаваш единица, така крайният резултат клони към нещо с повече нулеви битове. Примерно понеже паролите обикновено съдържат printable ascii символи, никога няма да се случи крайната стойност да имат символи над 128 в ascii таблицата (старши бит вдигнат), заради AND операцията, без значение дали salt стойността ги съдържа. XOR операцията не „редуцира“ ентропията по този начин.
юни 22nd, 2013 at 21:53
Здравейте на всички 🙂
вклювам се по темата за мултитаскинга на Apple за който говорите защото не сте го разбрали.След като изгледах видеата относно новите API-та в едно от видеата много ясно показаха къде ще е приложението на този мултитаскинг – главно в музикалните програми.Понеже освен development се занимавам и с музика и ще се опитам да го обасня това нововъведение.
Както знаете Apple от много време се водят за едни от най-добрите на пазара, що се отнася до създаване на музика и DJ-ing (много от DJ-ите пускат с Apple компютри и са част от пазарната ниша на Apple)
Откакто се появи iOS Apple създадоха първи един от най-добрите музикални апове – „Garageband“, след тях ги последваха и други доста големи компании от музикалнит бранш, като Steinberg Cubase, но на практика няма нищо ново и иновативно да създаваш копия на различни DAW(digital audio workstation-и) всички вършат почти едно и също нещо. Появиха се и други инди девелъпъри, който създадоха съмостоятелни аудио програми, като синтезатори и дръм машини, но за да запишеш звука от тези синтезатори и да продължиш с друга аудио обработка, досега(в iOS 6) трябваше да ползваш кабел за да запишеш звука с някое външно у-во като recorder или компютър след това да върнеш записания звук в Garageband или Cubasis. Нещо много непрактично…
благодарение на новата добавка в API-то на iOS, това вече ще се случва от само една програма и напрактика развързаха ръцете на девелъпърите на audio apps да правят 3-th part плъгини, който могат да се интегрират директно в Garageband или Cubasis, с това просто се разширява функциалността на digital audio workstation-ите.Като функционалност става така пускате си Garageband и го скривате в таск manager-а, но Garageband остава активен и може да приема аудио от друга активирана аудио програма, като да речем някой синтезатор написан от 3-th parts.В досегашните версии на iOS това не беше възможно.Може би това ще стимулира аудио девелупърите да разработват 3-th part плъгини за аудио програмите.
юни 22nd, 2013 at 22:17
Хмм и какви са точно правилата на тея нови API-та?
юни 23rd, 2013 at 00:10
@Stilgar, ще кача видеата и ще пусна линкове, едно от новите въведения в iOS и Mac Os е че можеш да си пишеш директно на javascript. Можеш да прочетеш тази статия
http://www.steamclock.com/blog/2013/05/apple-objective-c-javascript-bridge/
но имай в предвид, че вече е стара и някой неща са просто предположения от автора, има съществени разлики от това което е написал, и това, което Apple обявиха официално.
Относно новите audio API-та става въпрос за low level programming писани са на C, и има няколко нови класа (написани на Objective C), който се ползват като wrapper-и за да услеснят development-а, все пак е по-лесно да пишеш обектно в големи проекти.
юни 23rd, 2013 at 00:31
„Apple had promised to give devs „an in-depth look at what’s next in iOS and OS X“, and it certainly did that with a comprehensive look at the new iOS, detailing some of the 1500 new APIs that will be available for the developers to trawl through.“
http://www.techradar.com/news/computing/apple/ios-7-12-things-we-want-to-see-1111123
видеата, който ще кача са от WWDC 2013.
юли 2nd, 2013 at 20:26
http://programings.free.bg/articles/deep_hashing.html