BG Development


Страници: (2) [1] 2   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Проблем с UX
johnfound
Публикувано на: 27-08-2018, 09:41
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 6708
Регистриран на: 27.05.04



Сега, пишейки AsmBB форума ми възникна едни проблем донякъде свързан с UX донякъде с privacy-то.

Досега всеки можеше да чете всички постове и да редактира и трие тези, за които са му дадени права.

Сега обаче реших да правя ЛС, само че не във вид на поща, както е по повечето форуми, а във вид на теми, които имат ограничен достъп (limited access threads=LAT) - собственика на темата може да покани в нея който си иска и само поканените имат достъп до темата. Списъкът с поканените може да се променя по всяко време или при желание темата направо да се направи публична.

Направих ги, като ограничих видимостта на част от съобщенията и сега всеки може да гледа само публичните теми и тези от ограничените, в които е поканен.

Дотук добре, но се получи малък парадокс. Администраторите и модераторите не могат да видят LAT темите, ако не са поканени. Но могат да ги редактират, тъй като имат права да редактират всички теми и постове във форума. За да редактират LAT темата или пост от нея, те просто трябва да знаят ID-то им, което може да се види през SQL конзолата. Всъщност е доста просто.

Въпросът е накъде да я карам от тук нататък? Има няколко варианта:
  • Да направя някак си модераторите и администраторите да виждат всички теми, независимо дали са LAT или не.
  • Да направя така, че модераторите и администраторите да не могат да редактират такива теми.
  • Да оставя всичко както си е в момента.
Съображения по темата:

Ясно е, че администрацията на сайта винаги може да чете всичко, тъй като има достъп до базата данни. Редактирането и триенето през SQL конзолата всъщност е елементарно.

В този смисъл, понятието "private message" = "лично съобщение", както и пощенският вид на тази комуникация е заблуждаващ. Нищо "персонално" няма в такива съобщения.

Като прегледах малко сайтове и форуми по темата из Интернет, осъзнах, че повечето потребители, които не са програмисти имат искреното убеждение, че администрацията не може да чете личните съобщения. В повечето форумни енджини, нарочно е направено да няма такава възможност от стандартния интерфейс. Това води до това, че част от администраторите и модераторите също са убедени, че личните съобщения не могат да се четат. Но разбира се, има плъгини, които осигуряват такава възможност.

Аз именно с цел да избегна затова и избрах да не го правя чрез пощенската парадигма и смених термина от PM на LAT.

Мнения?

Това мнение е било редактирано от johnfound на 27-08-2018, 09:43


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 27-08-2018, 09:53
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1793
Регистриран на: 17.01.17



Сам знаеш, че е невъзможно, освен ако не ползваш криптография.

Така че, остава да се концентрираш върху възможните решения. Интерфейсът на форума не бива да позволява достъп до тези съобщения за потребителите и за модераторите (които обикновено са си потребители с повече права).

Администраторите имат права за достъп до всичко (включително и добавяне на нови плъгини) така че, там промяната на политиката за достъп си е по желание и не зависи от теб по никакъв начин.
PMEmail Poster
Top
johnfound
Публикувано на: 27-08-2018, 15:48
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 6708
Регистриран на: 27.05.04



QUOTE (thrawn @ 27-08-2018, 10:53)
Сам знаеш, че е невъзможно, освен ако не ползваш криптография.

Това повдига въпросът дали въобще е възможно, даже с криптография.

Имам предвид, теоретично мога да си представя такава система, която ще е условно извън контрола на администрацията:

двойка частен/публичен ключ се генерира на клиентската страна с JS и след това на сървъра се изпраща само публичния ключ. Частния ключ се пази като бисквитка или имаше някакъв нов сторидж в браузърите...

След това, съобщенията се криптират пак с JS на клиентската страна с използването на публичните ключове на участниците в дискусията и се пазят криптирани на сървъра.

Всеки си ги декриптира със собствения частен ключ пак на страната на клиента с JS.

Разбира се, администрацията на форума може да пусне модифициран скрипт, който да препрати на сървъра и частните ключове, но това лесно може да се хване от потребителя, тъй като той все пак има достъп до JS-та, който му се изпраща.

Остава въпросът има ли такова криптиране един-към-много, където аз криптирам съобщението с N публични ключа, а всеки получател може да го декриптира със своя си частен ключ?


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 27-08-2018, 16:02
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1793
Регистриран на: 17.01.17



Едно към много си е криптиране с частен ключ. По същество, това е цифрово подписване.

Иначе, да ,вариантът е да се ползват асиметрично криптиране а публичните ключове. Така само получателя на съобщението ще може да го прочете. Но тук вече системата ще стане доста по-тромава, тъй като ще се наложи именно локална реализация на сървисиът за криптиране/декриптиране (било то с js или с нещо друго).
Та въпросът е, до колко си струва това да се прави.
PMEmail Poster
Top
AK-85
Публикувано на: 27-08-2018, 16:46
Quote Post



Име:
Група: Потребител
Ранг: Старо куче

Мнения: 775
Регистриран на: 06.07.06



QUOTE (johnfound @ 27-08-2018, 14:48)
Разбира се, администрацията на форума може да пусне модифициран скрипт, който да препрати на сървъра и частните ключове...

Не, администрацията въобще не е нужно да прави това - достатъчно е да прати собствен публичен ключ вместо този на получателя, тъй като схемата, представена по този начин, е уязвима на MITM атака. Решението е да добавиш някакъв механизъм, който да удостовери, че даден публичен ключ отговаря на определена самоличност, и така лека-полека ще откриеш отново X.509.

QUOTE (johnfound @ 27-08-2018, 14:48)
Остава въпросът има ли такова криптиране един-към-много, където аз криптирам съобщението с N публични ключа, а всеки получател може да го декриптира със своя си частен ключ?

Ето го същият въпрос, но краткият отговор е не. Пак разгледай дискусията, че има нелоши идеи - примерно криптираш съобщението симетрично, а асиметрично криптираш само симетричния ключ, по веднъж за всеки получател. Ако съобщението е много по-дълго от симетричния ключ, е оправдано.
PM
Top
thrawn
Публикувано на: 27-08-2018, 17:02
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1793
Регистриран на: 17.01.17



В контекста на темата му, за мен е достатъчно да има двойка ключове за самата тема. Тези които имат достъп до частния ключ могат да публикуват. Тези които имат достъп до публичния могат да четат.

Тук може малко да се модне схемата като, всеки поканен може да получава сертификати издадени от двата ключа. Така така ще могат да се отнемат права, като се проверява дали някой от сертификатите не е анулиран.

Но разбира се, основния проблем си остава. Няма как да се гарантира размяната на ключовете.
PMEmail Poster
Top
johnfound
Публикувано на: 27-08-2018, 18:39
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 6708
Регистриран на: 27.05.04



QUOTE (AK-85 @ 27-08-2018, 17:46)
Не, администрацията въобще не е нужно да прави това - достатъчно е да прати собствен публичен ключ вместо този на получателя, тъй като схемата, представена по този начин, е уязвима на MITM атака.

Не споменах този вариант, защото схемата е достатъчно лесно разкриваема. Достатъчно е потребителите да си разменят публичните ключове по някакъв друг канал, за да цъфне измамата. Също вариант е един потребител да регистрира два акаунта и да установи, че публичните ключове се различават, в зависимост от кой ги гледа.

Защото за да работи такава схема, тя трябва да е постоянно активна. Докато варианта с прихващането на частния ключ работи само еднократно – един единствен път ти зареждат модифициран скрипт, а на следващия път пак оригиналния. Това най-вероятно ще се пропусне, ако не си взел предварително мерки всеки път да проверяваш еднаквостта на скрипта.

Както и да е, нямам намерение да правя такива лични съобщения, така че в момента си говорим чисто теоретично.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
Gamma Goblin
Публикувано на: 27-08-2018, 18:43
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1234
Регистриран на: 21.02.18



не си усложнявай живота, и дай на админите да четат всичко


--------------------
Напред! Живота е сраженье! Напред! И прав всегда ходи!
Напред, макар към поражение! Ако ще паднеш, прав падни!
---
Raw, and untamed in spirit, We chew this world and Spit it out
---
Challenge my own world to chaos
---
Im not intimidated by the good looking ones, it's the ugly ones that scare the shit out of me
PMEmail PosterUsers Website
Top
Golden Gega
Публикувано на: 27-08-2018, 19:18
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 974
Регистриран на: 04.06.10



Бъди мъж и издигни секюритито на принципно ново ниво.
Ей тук например хората показват първите плахи стъпки - например самоунищожаващи се съобщения. icon_evil.gif

https://www.ehacking.net/2015/04/open-sourc...-encrypted.html

Това мнение е било редактирано от Golden Gega на 27-08-2018, 19:27
PMEmail Poster
Top
johnfound
Публикувано на: 27-08-2018, 20:46
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 6708
Регистриран на: 27.05.04



QUOTE (Gamma Goblin @ 27-08-2018, 19:43)
не си усложнявай живота, и дай на админите да четат всичко

Точно този вариант и правя в момента. Но ще оставя тази функционалност само за администраторите. Модераторите ще трябва да я карат по-леко. icon_smile.gif

Това мнение е било редактирано от johnfound на 27-08-2018, 20:46


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (2) [1] 2  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2018 | BG Development | All Rights Reserved
RSS 2.0