De twofactor plugin waar jij het over hebt ziet op 2-factor authentication bij het inloggen op roundcube, en heeft verder niets te maken met PGP.
Lijkt mij niet. Inloggen stuurt geen wachtwoord maar stuurt een hashcode die moet overeenkomen met die in de server, tot webmail & PgP-key toegang, is opgeslagen.
Ondanks dat een leesbare wachwoord (bv login en pgp) uiterlijk dezelfde zijn, hoeft & zal dat niet gelden voor de te verifiëren (PgP) hashcodes.
Ik kan/wil mij wel voorstellen dat er via een uiterst ingewikkelde constructie, de passcode voor login ook wordt overgebracht, doorgezet & gebruikt voor hercoderen van die met PgP-sleutels.
Het wijzigen van je login wachtwoord betekent dan dat hashes van (private) sleutels zullen moeten worden vernieuwd. Ik geef het je te doen⊠en bedenk dat het voor jou gaat om zeg één sleutel en voor mij meer dan 50 (waarvan sommige weer tijdsgelimiteerd zijn).
Het hoe daarvan - login wacthwoord â pgp-wachtwoord) is het heschrijven van âloginâ zodat die (passkey?) te gebruiken is voor verschillende toepassingen. In de praktijk ook wel SingleSignOn (SSO) genoemd. Iets dat menige omgeving, laat staan zonder centrale authenticatie server, tot complete waanzin kan brengen.
Dat is om in te loggen, maar dat wachtwoord zou tegelijk vastgehouden kunnen worden aan de client kant. Vervolgens biedt de server de versleutelde privésleutel aan en die wordt lokaal met hetzelfde wachtwoord ontsleuteld.
Kun je dat toelichten? Je PGP private key heeft gewoon een passphrase die je kunt wijzigen. Die phrase (wel of niet aanwezig overigens) heeft geen enkele uitwerking op de versleutelde berichten die je maakt, want die worden immers op basis van je (opengemaakte) prive-sleutel gemaakt.
Het password waarmee de sleutel is gecodeerd, staat & komt bmw niet op de server terecht.
Wat wordt opgeslagen is, zo ja gebruikt het met wachtwoord gecodeerde, private sleutel.
Iets - bewaren private sleutels op server - dat sws niet is aan te raden en imo reden is voor de waarschuwing.
Ik kan het niet aantonen maar ga er stellig vanuit dat het wachtwoord ter beveiliging van dat risico, altijd in handen blijft van/bij de eigenaar zelf. Indien dat niet zo is, is het mechanisme (in webmail) zinloos.
Maar goed, onderzoek t.a.v. website-inhoud ivm javascript kan dat beeld aantonen of ontkrachten. Ik heb alleen even vluchtig bekeken. Geen tijd/zin om details op source-niveau uit te vlooien en ik ook geen toegang heb tot de geĂŻmplementeerde broncode als ingesteld bij Soverin/Freedom.
Wat (nog) zou kunnen is track/trace van packets of een PgP wachtwoord daarin fysiek - bij de aanmaak - dan wordt gecommuniceerd.
Terzijde: ik gebruik sws (laat staan met PgP in) geen confidentiële webmail omdat ik dat per definitie onprettig vindt en ik ook niet nog eens aparte sleutels wil moeten toepassen om webmail te scheiden van mijn verschillende offline clients.
Update: vanuit proefondervindelijk onderzoek (zie Freedom en end-to-end encryptie - 29 van net), blijkt dat het PgP wachtwoord wel in plaintext naar/in de server lijkt te komen en ik kan ik mij weer wentelen in de volgende desillusie.
Lijkt mij niet âwijsâ om je browserfunctie te gebruiken om dat soort passwords te onthouden.
Bezit van de browser is dan het eigendom claimen. Beveiliging van resources staat altijd op gespannen voet met onbelemmerde gebruik daarvan. reden dat veel mensen vaak dezelfde wachtwoorden gebruiken zodat ze âdoor kunnen werkenâ.
Overigens, kan iig FireFox ook wachtwoorden op client-formulieren - w.o. dus ook PgP velden - onthouden. Daarmee een volgende keer, dat wachtwoord invoeren door het vanuit een pulldown lijst te selecteren. In dat geval, is het weer raadzaam om te gebruiken browser als geheel, weer te voorzien van te minste een eigen (profiel) wachtwoord.
Eenmaal in RoundCube (webmail) de passkey ingelezen, cached de webmail-sessie dat wachtwoord. Iemand hoeft dus (per key) maar Ă©Ă©n keer een PgP-wachtwoord in te geven.
De private key wordt gegenereerd en dan (symmetrisch) gecodeerd met het wachtwoord.
Om die private sleutel te kunnen toepassen voor het decoderen van inkomend (bijbehorend publiekelijk) versleutelde mail, moet je de passphrase daarvan weten.
De private sleutel zelf is - natuurlijk - niet in gebruik bij aanmaken van uitgaande mail (waarbij je dan andermans publieke sleutel gebruikt).
Als en indien er een koppeling tussen Login en PgP wachtwoord wordt geĂŻmplemnteerd, zal bij wijzigen van een login dus ook de daarmee beveiligde private-sleutels opnieuw moeten worden ge-passphrase-d.
Om te voorkomen dat iemand een oude passphrase nog kan toepassen (met mogelijk een eerder verkregen private sleutel), zal de private-key en dus bijbeborend publieke sleutel moeten worden vervangen.
Het alleen een ander wachtwoord op de private key aanbrengen is wmb nutteloos.
Zojuist even met een sniffer getest in de webmail en bij het instellen van de PGP identity gaat het wachtwoord toch echt plaintext in de HTTP POST naar de enigmakeys plugin op de server.
Volgens de broncode van die plugin zal de enigma_engine.php vervolgens het wachtwoord opslaan in de global PHP session. Versleuteld middels de RoundCube encrypt() functie en de algemene des_key uit de RC config.
Dwz: de webserver, PHP instance en alle (third party) RC plugins en skins hebben toegang tot je wachtwoord.
Edit: als er een WAF draait die de request body scant dan staat je wachtwoord mogelijk ook nog ergens gelogd.
Thx. dan lijkt het bottom-line wat zinloos is om PgP in Webmail toe te passen en trek ik mijn veronderstellende keutels in.
Een vraag is dan of ('m waarschijnlijk beanbtwoorden) of te importeren en beschermde private sleutels evenmin veilig zijn (wanneer de PHP-serverfuncties worden gebruikt).
Ik vraag mij dan ook af wat het doel moge zijn dit zo toe te passen, anders dan ter veronderstelling te doen alsof het een bescherming biedt op vertrouwelijke inhoud.
Een instantie kan (dan) simpelweg volstaan om die plaintext communicatie (landurig) te monitoren. Dat iets of een ander dat niet zal/zou willen doen, is struisvogelen.
Benieuwd of zo ja Freedom dat op privacy-waarde ziet om meer inzicht te geven.
Voor E2EE is serverside handling nooit een oplossing. Ook al zou de plugin de encryptie in clientside javascript doen, dan nog blijft de mogelijke kwetsbaarheid van een derde partij aanwezig. Het is altijd beter om de keystore en crypto lokaal te doen en de webmail, smtp of chat apps alleen als transport medium te zien.
Eens, en dat maakt E2EE in applicaties zoals whatsapp zo schimmig op dat punt, omdat je helemaal niet kan zien of controleren waar die sleutels nu eigenlijk zijn, wie ze allemaal heeft, en hoe ze gebruikt worden, of voor welke sleutels ze versleutelen.
Deels zeker eens. Het lijkt mij wel denkbaar dat je clientside de data wel veilig zou kunnen encrypten mits weer controle mogelijk van de gebruikte code. De praktijk is dat dit niet te doen is.
De onzekerheid is gelegen dat code serverside, de vanuit daar gedistribueerd & specifiek afgestemd, inhoudelijk kan zijn aangepast.
Deels geldt dat ook lokale code waarbij moet worden vertrouwd op de asynchrone bron die (open source) niet zo makkelijk (ongemerkt) is te compromitteren om specifiek een persoon/groep te treffen.
EĂ©n van mijn redenen dat ik niet niet zomaar update doe omdat iemand anders dat een goed idee vindt (en ik dan weer door een molen van check & balance moet). Periodiek een sweep doen op gebruikte programmacode-hashes, kan malversaties detecteren.
Het is op zich niet slecht dat ze het aanbieden. Serverside versleuteling is beter dan helemaal geen versleuteling. Een extra beschermingslaag.
Voor E2EE kan je het ook stapelen door eerst de inhoud op je client device te versleutelen en het resultaat met een andere key in de webmail PGP. Dan zijn het bericht Ă©n het transport veiliger, ook al kunnen andere processen meekijken. Wel een gedoe steeds en de beoogde ontvanger moet daar ook van op de hoogte zijn.
Ik vind het als âhalf ietsâ dat beter kan, hierin een schijnoplossing. Niet als afwaardering maar had verwacht dat plaintext wachtwoorden in sessies niet worden gecommuniceerd.
Maar goed, khad sws al geen enkele animo om webmail voor dit soort dingen toe te gaan passen.
Dat instapelen (re-keying) kan ook zonder webmail, dat hier dan uitluitend dient als online transporteur. Ik ken situaties die gebruik maken van rekey/facility codering die aanwezigheid van de ander noodzakelijk maakt om een inhoud te verwerken.
TB kan het ook en slikt ook sleutels+pass in.
Hij zet er wel een andere pass op.
Vraag me af of het wachtwoord van het mail account invloed heeft op de pass van de key op de server?
De keys die de webmail aanmaakt, zijn ook niet meer van deze tijd.
In mijn beleving de Bart Smit versie van versleutelen.
Er zijn ook mensen die zeggen dat mijn drang om te versleutelen voort komt uit mijn paranoia.
Wil mij zelf altijd wel vermaken dat wanneer ik iets beveilig, anderen dat gebruiken om hun waarde (oordeel) uit te spreken. Doet mij denken dat als je de aandacht wilt trekken daarop âgeheimâ of âvertrouwelijkâ moet plaatsen.
Dat webmail kan versleutelen is ook in mijn beleving dan met de gedachte dat het beter is dan niets. Het pijnlijke hier is dat het pure schijn is.
Het wachtwoord van een mailaccount, staat los van de key.
Ik ben nog steeds flabbergasted dat ook de PgP wachtwoorden hier met webmail, in plaintext letterlijk 1:1 zo de lijn overgaan en dus bij Freedom/Soverin bekend kunnen zijn:
"postData": {
...
"text": "_keyid=0123456789ABCDEF&_passwd=plaintext&_token=AZaz09AZaz09AZaz09AZaz09AZaz09AZ&_unlock=loading1234567890123"
}
NB: ook de login van webmail is/was, naar ik bekend veronderstel, gebeurd in klare tekst.
Wel weer blij dat het vermoeden mij - altijd - heeft afgehouden om webmail te gebruiken voor wat vertrouwelijk kan zijn niet via webmail, te beantwoorden.
Iets nu niet triviaals kan natuurlijk wel weer belangerijk zijn of worden, voor tzt een ander.
Wanneer mensen aanmerkingen maken, herhaal maar het bekende riedeltje:
Webmail en PGP zijn sowieso een lastige combinatie om goed te doen. Daarvoor moet je eigenlijk alle crypto client-side doen en zo ben ik het zelden tegen gekomen. Alle andere configuraties leiden ertoe dat de private key + passphrase naar de server moeten en dat gaat in tegen het idee van een private key.
Kleine nuance: Webmail draait uiteraard wel over TLS. Daarbinnen is het inderdaad plain text. Ik mag hopen (maar kan niet controleren) dat in de database wel een variant staat die gehashed is met een random salt per account.
Delta chat (waar dit topic mee begon) ziet er wel interessant uit, heeft iemand er inmiddels ervaring mee?
Zo werkt webmail nu eenmaal. Je browser gebruikt hier overigens sessie cookies voor, dus al die informatie is weer weg als de sessie weg is.
Ik doel op de ingebouwde passkey functie van browsers die zo makkelijk je userid en wachtwoord combinaties kunnen onthouden.
Dat een sessie, standaard, een eenmaal ingegeven PgP wachwoord gaat onthouden, lijkt mij ook niet perse wenselijk. Iets dat menig mailclient helaas doet (als ze al PgP passwords supporteren) en de gebruikers moet zorgen dat de mailsessie wordt afgelogd wanneer die even elders is.
Ja, ik zie dat er altijd betere oplossingen zijn, maar laten we het in stappen in ieder geval de juiste kant op brengen.
Wat zou een haalbare manier zijn waarmee Freedom Internet klanten van een veiliger communicatieplatform kan voorzien? Op dit moment zijn er best veel obstakels of moet je ergens anders weer een abonnement afnemen voor een geschikte dienst.