Weboldal textbox tartalom folyamatos titkosítása

Security-all

Sziasztok,

Nem tud valaki olyan megoldásról, amellyel egy adott weboldal adott beviteli részét meg tudom jelölni, és egy előre beállított jelszóval mindig titkosítja szimmetrikus titkosítással?

Ezt lehetne mindenhová használni, pl. google mail, chat stb. és a shared secret is elég kényelmes ahhoz, hogy hosszú távon jó legyen - feltéve ha megjegyeztethető lenne hogy melyik weboldal melyik objektuma milyen jelszóval lenne automatikusan titkosítva.

Köszi-

Nulladik lépésben azon gondolkodj el, hogy a textinput-ot js-ben a te kódod lefutása előtt el tudja fogni az oldal, úgyhogy elég nehéz úgy titkosítani a böngészőn belül, hogy biztosan ne legyen lehetőség a bevitt tartalmat a titkosítás _előtt_ feldolgozni/továbbítani.

( log69 | 2014. 11. 18., k – 22:10 )

Nem lenne érdemes firefox-éknek leadni feature request-ként? Egyszerű lehetne implementálni. És milyen jó lenne.. csak jobb egér egy textbox-on és beírni a jelszót azt annyi. Onnétól az azon az oldalon abba a box-ba írt szöveg mindig titkosítódna elküldés előtt - és egy megjelölt másik objektumon meg a fordítottja.

( Apo | 2014. 11. 19., sze – 03:20 )

Egy hasonlot mar kitalaltak... ugy kezdodik, hogy https...

( sz332 v | 2014. 11. 19., sze – 07:25 )

Ennek 1: mi értelme van? 2: a https miért nem jó?

A szolgáltató elől is el akarom rejteni a tartalmat. https-sel még google például hozzáfér a levelekhez - de nem csak google, freemail és egyébhez is jó lenne egy egyszerű, univerzális titkosítási lehetőség sima jelszóval.

Titkosított chat-hez is pl. Lehet nem fogalmaztam világosan.

Szóval hogyan tudnánk használni a nagy szolgáltatók szolgáltatásait titkosítással? Ez a kérdésem. (A chrome + gmail titkosítási lehetőségről tudok, de nem csak google tartalom titkosítása érdekel, hanem egyéb is).

Ha a szolgaltato elol akarod elrejteni akkor PGP/GPG es lokalis email kliens (vagy sajat szerveren futo webmail).
Titkositott chat letezik (plugin formajaban nepszerubb kliensekhez) es sajat jabber szervert is csinalhatsz.
A nagy (ingyenes) szolgaltatok/szolgaltatasok a reklambol elnek, amit neked tálalnak. Ha nem tudjak elolvasni a leveled, akkor nem vagy tul ertekes ugyfel.

Kivancsi lennek egy titkositott uzenetekbol allo FB uzenofalra :)

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

A célom valóban az, hogy a szolgáltató elől való elrejtés (pl. könyvelési adatokhoz információ küldése - vagy egy ügyfélnek az adataival kapcsolatban információ átadása - sok a lehetőség). Viszont mindezt úgy, hogy a távoli kapcsolatom egy egyszerű user. Az asszimetrikus titkosításhoz kulcsokat kell kezelni, ez már eleve bonyolult. Illetve elveszhet a kulcsa stb. Ennél már az is jobb ha bediktálok neki telefonon vagy személyesen egy erős jelszót és azt megjegyeztetjük sok évre. Ez a kényelem, egyszerűség kontra biztonság szempontjából a legjárhatóbb út nekem.

A titkosított üzenőfal ötlet poénos :)

Ha ez a helyzet akkor szerintem titkositott kommunikaciora csak sajat szerver a megoldas, rajta webmail (https) vagy egy webform ahova beirja az uzenetet (szinten https+auth), termeszetesen akkor ha a PGP+email kliens nem johet szoba.

Ingyenes (random) szolgaltato eseten szerintem egyszeru megoldas nincs. Sot, ha barmilyen mas megoldast hasznalsz az adatokat attol meg ellophatja egy keylogger/trojan a tavoli geprol, foleg ha nem hozzaerto a felhasznalo.

Esetleg kuldozgethettek jelszavas zip-eket, nem tudom azt mennyire bonyolult kezelni a felhasznalonak.

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( Frantique v | 2014. 11. 19., sze – 10:53 )

Nem értem, mi a valós cél ezzel. Egy titkosítás akkor értelmes, ha a másik oldalon van, aki kititkosítsa az adatokat. Onnan viszont már megint olvasható. Lássuk a lehetséges forgatókönyveket:

1. SOCKS proxy (bővebben itt: http://lifehacker.com/237227/geek-to-live--encrypt-your-web-browsing-se… )
2. Javascriptes szövegmező ki-bekódolás kiegészítővel (ez macera, és kb. fölösleges, valahol át kell küldeni a kulcsot, máris bukta van, lásd Enigma esete a történelemben).
3. A kommunikációt átvinni titkosított csevegőre.
4. Sz**ni bele a titkosításba, inkább magunkat titkosítsuk, bújjunk el Tor mögé.
5. Kiülni egy parkba a másik féllel, és szépen beszélgetni. Analóg módon. :)

Melyik szimpatikus?

--
Coding for fun. ;)

Egyszerű userrel kell megoldanom, ez a probléma. Technikai személlyel nem lenne gond természetesen (bár kényelmi szempontból ott is lehet problémás).

Tehát a jó öreg kérdés: hogyan csináljunk adat biztonságot két fél között, ha a feltétel az egyszerűség és kényelem?

( Winter | 2014. 11. 19., sze – 11:05 )

Azt hiszem sejtem mire gondolsz, de miért szimmetrikus titkosítás?
Mivel itt van egy küldő, és egy fogadó, lehet az aszimmetrikus szerencsésebb lenne.
Tegyük fel, te vagy a fogadó: ahhoz hogy neked küldjön valaki, ismernie kell a kulcsot. Az első esetben ha kiszivárog tőle a kulcs, azzal bárki visszafejtheti a neked szóló üzeneteket, ha hozzájuk jut (jó, persze minden küldés előtt kérhet újat de azért...), míg ha csak a publikus kulcsot veszti el, nem történt semmi. Igazából reklámozhatod is, hogy bárki küldhessen neked titkosítva (mint a pgp-s levelezésnél). Így pl. a HTML form is tartalmazhatna egy statikus kulcsot, a böngésző/plugin pedig azzal kódolhatna post előtt. Ez amúgy talán JS-sel is megoldható lenne, így működhetne bárhol böngésző, és verzió függetlenül, plugin telepítgetés nélkül.

Bye Bye Nyuszifül - DigitalOcean referrer, mert az jó - <3 openSUSE, Ubuntu, KDE <3

Az asszimetrikus bonyolult (kulcsok kezelése, elvesztése stb), illetve nem elégséges az, ha valaki a publikus kulcsommal küldd nekem üzenetet, mivel attól még nem lehetek biztos a személyében. Tehát itt ugyanúgy van shared secret - maga a kulcsok kicserélése. Akkor meg minek bonyolítsuk? Egy erős jelszó mindennél egyszerűbb gyakorlati szempontból.

JS is képbe jöhet, de a kérdésem továbbra is az, hogy konkrét jó megoldást ismer-e valami? Úgy, hogy kihasználhassuk a nagy szolgáltatók által nyújtott infrastruktúrát (gyors elérések stb)?

Mert ezen kívül persze én is tudok megoldásokat (pl. chatcrypt.com). De Gtalk chat-hez pl nem.

Ötletek?

>aszimmetrikus
>shared secret

Are you even trying? A shared secret itt konkrétan az, hogy a publikus kulcsot kitolod a netre, vagy egy plaintext emailben elküldöd, aztán telefonon/személyesen megerősíted, hogy egyezik-e a fingerprint, tehát menet közben nem lett eltérítve a kulcs.

Hol itt a shared secret? A PGP lényege pont az, hogy titkos üzenetet bárki küldhet neked a _publikus_ kulcsoddal, amit a priváttal kinyitsz. Ha a privátot kezded osztogatni, már rég rossz.

A chatcrypt.com miert garancia arra, hogy a szolgaltato nem latja a kommunikaciot? :)
Gmail is https-en megy, tehat azt sem latja. Mondjuk tisztazni kell, hogy melyik szolgaltato akinek nem szabad latnia, helyi ISP vagy Google es tarsai.

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( log69 | 2014. 11. 19., sze – 13:17 )

És valami rendkívül egyszerű, minimális kódbázisú, design-tól mentes open source fejlesztést nem ismer valaki, amelyet saját szerverre tudok tenni és ott chat-et biztosít? Esetleg HTML5-öt használva hangjelzést is tud? És statikus (tehát csak JS-ből fut)?

Így van, erre gondoltam. Van valaki sockjs meg Websocket - html5-tel ezt még nem lehet megcsinálni? Láttam demót p2p-re csak chat-ből - valami westernes design-ja vol a weboldalnak - nem tudom megtalálom-e.

Vagy ezek?
http://peerjs.com
http://dev.w3.org/html5/websockets/

Vagy milyen lehetőség lenne közös objektumot elérni két távoli kliens böngészőjéből azonos weboldalon?

Szerk.: nem ide tartozik, de ez is érdekes - JS-ből p2p:
https://peercdn.com/screencast.html

Amire használnád arra a CryptoCat valószínűleg megfelel.
https://crypto.cat/
https://en.wikipedia.org/wiki/Cryptocat

Esetleg még a minilock, az a nyáron még nem volt stabil.
https://minilock.io/
http://www.wired.com/2014/07/minilock-simple-encryption/
--
Légy derűs, tégy mindent örömmel

( log69 | 2014. 11. 19., sze – 15:28 )

Nem lenne kedvetek összeötletelni és összedobni egy olyan egyszerű szerver oldali scriptet, mellyel megvalósítható lenne egy biztonságos chat és minimális kódbázisra és maximális biztonságra törekednénk minimál design mellett CSS nélkül mondjuk Ruby-val megoldva?

Nem vagyok paranoiás, hanem igény van egy olyan megoldásra, amely kényelmes és biztonságos is elfogadható módon. Erre kérdezek itt véleményt hogy van-e ilyen lefejlesztve.

A meglévő nagy felhő szolgáltatóknak meg jó a szolgáltatásuk nyilván - nagy erőforrásuk van - és ezt jó lenne kihasználni. A kérdés az, hogy megtudnánk-e oldani ezzel?

Ha nem, akkor marad a saját szerver - ami megint nem gond, csak ott ugye sok kérdés felmerül - meg kell adnom a hozzáférést, hogyan fejlesszem le - hogyan jelezze a beérkezett üzenetet - lehet pityegtetni? stb

Egyébként az a gondom, hogy napjában sokszor kell érzékeny adatokat küldenem - jelszavak új fiókokhoz, egyéb adatok cégről - és a jelenlegi megoldásokkal nem kivitelezhető - marad az emailben titkosított adat küldése, telefonon meg bemondom a jelszót - nem látok más lehetőséget egyszerű usernek - adminnak lehet gpg-vel, de sima userrel van a probléma - meg jó lenne ha mobilról is elérhető lenne stb

Szerintem egy saját szerón/VPS-en futó XMMP szerver lenne az optimális megoldás.
Az utóbbi havi 5$-ból lazán kijön. Én DigitalOcean VPS-t használok, de van kismillió más szolgáltató, olcsóbb is.

Bye Bye Nyuszifül - DigitalOcean referrer, mert az jó - <3 openSUSE, Ubuntu, KDE <3

( log69 | 2014. 11. 19., sze – 19:02 )

Amúgy köszönöm mindenkinek a tippeket és ötleteket. Lehet mégis egy felrakott xmpp szerverrel jövök ki a legjobban és leghamarabb.

( asch v | 2014. 11. 19., sze – 21:38 )

Van egy olyan fából vaskarika, hogy általában az ingyenes szolgáltatóknál tiltott a plusz egy rétegben használt titkosítás. Tehát gmailen a titkosított adat küldése úgy általában. (AFAIK) Ezért csak a saját szerveres megoldás marad.

Sőt, volt olyan hír is, hogy aki olyan megoldásra keres, amivel biztonságosan kommunikálhat, az azonnal az NSA látókörébe kerül.

( log69 | 2014. 11. 19., sze – 22:01 )

Nem kell ilyen másnak egyébként? Nem lenne kedvetek együtt lefejleszteni? Pár nap alatt meglehetne kényelmesen. Egy szál szerver oldali rövid script azt kész. Statikus HTML4-et dobna ki, meg felette minimál JS a vizsgálathoz hogy van-e új üzenet a másik féltől.