Nou ik was het niet in elk geval @ "07:50 door donderslag - Bijgewerkt: Vandaag, 08:11 " in het inlichtingen - Volkskrant topic wat gelukkig gesloten is. Deze reageren uit onvrede. Die periode heb ik ook doorgeleefd. Zo'n topic wordt snel politiek en men gaat op de persoon spelen hier op de site en gelukkig komt er dan een slotje op. Gelukkig ben ik steeds minder frequent op internet te vinden. Of lees ik alleen nog zonder te reageren.

Inloggen met een wachtwoordmanager is sneller dan een tekstbestand wijzigen. Ik denk dat de mensen die even snel iets plaatsen geen " crypto " backlog gaan aanleggen.




Ik raad een account aan. Ik heb al meegemaakt dat mensen (weet nu ook wie) mij gedoxt hadden en mijn quote misbruikten. Ik heb me daar nadien en daardoor ook schuldig aan gemaakt op een nieuwssite maar ben daar mee gestopt. Dat was onderdeel van een proces waar ik nu uit ben.

Het is natuurlijk handig om anoniem te posten maar ik ben door schande en schaamte of beter gezegd ervaring wijzer en minder rebels op privacybeleid en daardoor ook voorstander van verplichtte registratie. Dat de moderatie hier accountloos toelaat is heel nobel. Zolang het een eigen security.NL database is en geen "inlog met Facebook, Disqus of Google".

Soms zijn minder woorden beter, dan springt de useful stuff er tussen uit. De techniek, daarvoor zijn we hier. Jouw posts zijn daar altijd een voorbeeld van. Dus daar ga ik ook persoonlijk een voorbeeld aan nemen. Verfrissend en professioneel, iets wat me doet denken aan vroeger. Meer op de techniek toegesneden in plaats van op reacties van andere personen met ieder zijn eigen onderbuik aan het woord.

Het kaf van het koren scheiden wordt met de tijd steeds een eenvoudigere zaak als je ziet wat voor topics hier worden aangemaakt met vragen ("Wat is een daemon process?". Dingen die je maar hoeft te googelen. In elk beginnersboek staat dit uitgelegd. Het is opmerkelijk dat dit nog door de moderatie komt.

Je kunt ook gewoon een account aanmaken.

Zoals ik schreef, ik verwacht niet dat dit opgevolgd gaat worden (in elk geval niet massaal). Maar wie weet heeft iemand er een slimme toepassing voor. Zoals een dissident die met een journalist communiceert en anoniem wil blijven, maar waarbij er bij de journalist geen twijfel mag bestaan dat het steeds om dezelfde dissident gaat.

Ik realiseer me dat dissidenten in sommige landen terrroristen worden genoemd; je kunt dit soort technieken goedschiks en kwaadschiks gebruiken. Maar ook dit is een voorbeeld van dat je cryptografie niet moet willen backdooren om "boeven te kunnen vangen", want die boeven maken dan hun eigen protocollen wel (dat is doodsimpel zoals je hierboven lezen), terwijl brave burgers het -enorme- risico lopen dat de sleutel van de backdoor in de door hen gebruikte software/hardware in verkeerde handen valt.

Waarom post je dan anoniem?

Gegeven een TS-bijdrage waarin staat: "In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken". Dan kun je die tekst natuurlijk niet lezen en toch menen iets zinvols aan de discussie bij te dragen met jouw post. Om niet te worden uitgelachen door mensen die weten wie jij echt bent, kun je zoeits inderdaad maar beter anoniem doen. De kans dat jouw bijdrage gelezen wordt is dan trouwens ook groter (van trollen met een account weten serieuze bezoekers van security.nl meteen welke bijdragen ze kunnen overslaan).

Uit https://www.security.nl/posting/626870/Sudo+rechten+geven+en+schade+beperken#posting628127:
In theorie kan dat, en security.nl zou zelfs een cryptografische hash van die browser-fingerprint kunnen maken om die informatie "echt" te anonimiseren. En laten we ervan uitgaan dat de beheerders van security.nl te vertrouwen zijn.

Maar wat als je een willekeurige andere site bezoekt die wel browser-fingerprints van bezoekers verkoopt of publiceert, inclusief jouw IP-adres? Dan heeft die hash geen zin meer, want die kan iedereen dan opnieuw uitrekenen en vergelijken. Security.nl zou natuurlijk, via security by obscurity, een geheim aantal keren het hash-resultaat kunnen hashen (zoals ik hierboven ook doe), maar vroeger of later lekken de details van zo'n methode uit. Dat kan bijv. doordat een bezoeker van security.nl zelf gaat experimenteren met allerlei hash-combinaties, net zo lang tot zijn browser-fingerprint tot de door security.nl getoonde hash leidt.

Dit is precies het probleem bij het proberen te anonimiseren middels hashes: als je een specifieke input kunt voorspellen, of als je alle mogelijke inputs kent of kunt beredeneren, en het daarbij niet om gigantisch veel mogelijkheden gaat (geen hoge entropie dus), biedt het publiceren van slechts het resultaat van een cryptografische hashfunctie geen enkele privacybescherming (vandaar dat de randomness, lees onvoorspelbaarheid, van het uitgangsgetal in mijn TS-bijdrage zo belangrijk is - en je dus niet random.org moet gebruiken).

Zo is het hashen van telefoonnummers, IPv4-adressen en MAC-adressen "om de anonimiteit van de eigenaar te waarborgen" complete snake oil, want je kunt redelijk snel een tabel (bekend als rainbow table) maken van alle mogelijke waarden en de bijbehorende hash. En vervolgens kun je, gegeven een hash, heel snel de bijbehorende input opzoeken - weg anonimiteit.

Het enige, doch matige, wapen hiertegen zijn functies als Argon2, maar ook daarmee "gehashte" informatie wordt, na verloop van tijd, steeds makkelijker te "kraken". Desgewenst wil ik daar wel wat over schrijven.

Aanvulling: het stuk helemaal bovenin deze bijdrage was weggevallen, dat heb ik herschreven.

Wordt een soortgelijk principe niet toegepast door sites als 4chan?

Leuk bedacht. Als toevoeging zou ik willen suggereren de naam van het algoritme aan elke regel toe te voegen:

Hieronder een implementatie in Python, waarvan (als je het onder de naam hashseq bewaart en uitvoerbaar maakt) het volgende commando bovenstaande uitvoer (maar dan met andere hashes) oplevert:
Als iemand de laatste regel in een eerdere post heeft gebruikt en nu de op een na laatste gebruikt, dan controleer je het zo:

Hieronder de Python-code, die helaas NIET goed zal worden weergegeven omdat security.nl binnen de code-tag voorloopspaties platdrukt, en die zijn belangrijk in Python.

@REDACTIE: dit is doodeenvoudig te verbeteren, door in core.css, regel 1790, aan div.markup-config dit toe te voegen:

white-space: pre

Een monospace font is niet voldoende voor code.

Voor wie met de developer tools in browsers uit de voeten kan: je kan het daar voor de duur van de weergave van de pagina zelf toevoegen, zodat het goed wordt getoond.

En natuurlijk even ondertekenen:
sha256:b88bf8144c60616ae29de39e0deba5279c10ee32edf797f108b0bb1aa1c26cae

Ik beloof niet dat ik dit vol ga houden, maar het is leuk om er even mee te spelen ;-)

TL;DR

Al mijn bijdrages zijn al uniek. ;)

Dan is meteen bekend dat die dissident op security.nl zit ;) Ergens anders ben ik deze truuk nog niet tegengekomen.



Het valt aan te bevelen om dit soort methodes altijd te gebruiken, ook voor mensen die paranoide zijn en wat gemoedsrust willen, voor ICT'ers die met mensen communiceren over niet betrouwbare platformen (smartphone) of platformen die suspectible zijn aan MiTM attacks bijv. door staten die zich bedienen van Entrapment (dichter bij als je denkt) bijv SMTP wat gewoon plaintext is. Als je de originele email weet tegen te houden met een client-site error aan deze of de andere kant dan kun je een gemodificeerde mail op de originele tekst (of variant ervan) spoofen. De mogelijkheden zijn eindeloos. Zo'n checksum verificatie systeem zou eigenlijk iedereen moeten gebruiken.

Waarom post je dan anoniem?
[/quote]
Makkelijk toch? Ik ben niet zo bezig met wie wat schrijft hier op de site maar ik kan mij voorstellen dat het zeer vervelend is voor vaste gebruikers. Alle disinfo en kinderlijke reacties daar weet ik inmiddels wel doorheen te prikken.

Bovendien is een accountje zo gemaakt ook door spammers. Iemand die zijn integriteit hoog in het vaandel heeft zal inderdaad zo'n hashfunctie gebruiken in posts eventueel in combinatie met account.

Er zullen zeker enkele mensen op security.nl wakker zijn nu en een hashfunctie gaan toepassen in de posts. Dit idee werd al toegepast op moderne BBSen waar de gebruiker bij het posten een wachtwoord opgeeft via een HTML form input functie. De php van de site genereerde dan de hash. Deze hashes en tripcodes kunnen wel gekraakt worden, zeker door inlichtingendiensten met rekencapaciteit. Het beste blijft daarom een combinatie van methodes.

Niet alleen voor dissisenden maar ook de mensen die ongeterecht worden getarget door de groeiende private (minder met regeltjes en wetten) surveillanceindustrie. Dat wordt alleen maar meer in de toekomst. Ik val in die laatste categorie. Misschien moet ik zelf maar een bedrijfje opzetten in de surveillance, de truuks ken ik inmiddels al en ik kan gaan oefenen op wie mij target, zeg maar de concurrent van mijn nog niet bestaande eigen toko. Volgens mij valt hier goed in te verdienen.

Gegeven een TS-bijdrage waarin staat: "In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken". Dan kun je die tekst natuurlijk niet lezen en toch menen iets zinvols aan de discussie bij te dragen met jouw post. Om niet te worden uitgelachen door mensen die weten wie jij echt bent, kun je zoeits inderdaad maar beter anoniem doen. De kans dat jouw bijdrage gelezen wordt is dan trouwens ook groter (van trollen met een account weten serieuze bezoekers van security.nl meteen welke bijdragen ze kunnen overslaan).
[/quote]
Er is nog een reden om het niet te doen voor sommige mensen: Aan de hand van de hashfuncties in posts kun je een volledig profiel van de historie van iemand opbouwen. Die tekst kun je laten analyseren en met ML learning laten fingerprinten. Er ontstaat dan een digitale vingerafdruk van jouw grammatica en vocabulair waarmee je dus een deel van je privacy verliest.


Dat is leuk, dan kan de site bezoekers meteen vertellen wanneer ze een onveilige browser hebben met tips op een doorklikpagina.


Een hacker kan zich ook toegang verschaffen tot jouw systeem of router of smartphone (waarschijnlijk het makkelijkst) en vanaf de shell een python scriptje draaien om ergens iets te posten of een site te pingen en voila jij bent het geweest.


Ik was met rainbow tables bezig toen ik een tiener was, toen bestonden rainbow tables nog niet. Ik bedacht het voor een functie waarvoor alleen maar CPU-kraakprogramma's waren maar met de processoren van toen (286 386) duurde het uren of dagen. Zo'n hash betrouwbaar genoeg voor het opslaan van wachtwoorden (ja gehashte wachtwoorden opslagen gebeurde toen al).


Dan ga ik dat nog eens opnieuw lezen. En dat is meteen het voordeel van een account.

Nog een nadeel van zo'n hashfunctie in posts op deze site of elke ander forum is dat het zinloos is als de beheerder of een moderator onbetrouwbaar heeft of als iemand toegang heeft tot de database. In dit geval kan de content van jouw bijdragen worden gewijzigd maar met jouw hash eronder. Het werkt dan averechts want iedereen zal zeggen dat jij die ene post hebt geschreven omdat jouw hash eronder staat. Jij kunt die post niet meer aanpassen. Met een account zit je toch altijd beter, je kunt altijd nog oude posts editen en corrigeren.

Ja. Zij werken met tripcodes. De worden om de haverklap gehacked. Alleen de eerste 6 of 8 karakters zijn gehashed. Het komt op hetzelfde neer als de hier voorgestelde sha,md5 hashes. Voor deze heb je alleen zware rekenkracht nodig en dan heb je alleen de volgende opstakels:

- inlichtingendiensten met een dedicated hash crack service/server rack voor hun personeel

- zware hackers met teveel geld die een station hebben met honderden terabytes aan rainbowtables (een mini versie van voorgenoemde)

- het risico dat een moderator of hacker toegang heeft tot databases of posts en deze kan editen (op elk board of forum zoals phpbb en vbulletin kan een moderator de INHOUD van posts veranderen) dus dan zegt zo'n hash niets over de consistentie van de posts

Zelf neem ik niemand serieus die geen PGP gebruikt. Eventueel in combinatie met AES-Twofish of een andere cipher in cascade. Het probleem bij die laatste is dan wel de leesbaarheid van je geposte data want die moet je ontsleutelen. Dan moet je een Javascript ECB/CBC implementatie gebruiken zoals in [1]. PGP kun je in signfunctie gebruiken, dan hoeft de overheid niet te zeggen "wij kunnen je niet lezen" maar dan kun jij wel zeggen "de integriteit van mijn mails zijn redelijk betrouwbaar", moet je je private key natuurlijk niet opslaan op een PC met internet toegang of bij je provider. Zo kunnen ze de terrorisme / pedo kaart niet spelen en kun jij nog vertrouwen op de infrastructuur. Het is jammer dat zo weinig mensen gebruik maken van PGP. In de jaren 90 was dit heel populair op Usenet. In een HTML omgeving vind men dit blijkbaar niet schoon meer, wat een estetische kwestie is maar juist in HTML kun je board software ontwerpen waarbij de PGP headers van een "reaguurder met kennis van zaken" standaard worden weggepoetst totdat je op een HTML knopje drukt om de volledige tekst (met headers) te downloaden voor offline verificatie door jezelf - of nog een balkje op de forum software die aangeeft [deze post bevat pgp: signatuur oke/niet okee]. Als ik een forum zou ontwerpen zou ik voor dit laatste kiezen. Het is een kwestie van de bestaande php van een forum aan te passen, met een sed functie de PGP headers te identificeren en strippen voor het leesmgemak en als deze er zijn even lokaal op de server te verifieren met een groen/rood indicator bij elke post en eventueel de optie om de volledige source te downloaden. Een paar uurtjes sleutelen en je bouwt een forum om tot PGP grade integrity. Een aparte upload.php voor de keys (eenmalig) is binnen minuten gecodeerd.


[1] https://github.com/wouldgo/twofish

Oke, even in het kort. Ik denk dat dit voor security.nl een primeur kan zijn als zij dit willen coden. Maar je kunt zelf ook vbulletin aanpassen.

PGP op een forum? Waarom niet. Dit moet je doen:


1. PGP sleutels uploadbaar via security.nl/uploadkey.php en die via system() of passthru() laten importeren in de serverside PGP database. 20 regels php code of minder met alle validaties en checks


2. In de php van /posting of waar die rewrite rule voor staat elke post nalopen op PGP content (boolean aan) en de "rommel" strippen (-----BEGIN PGP MESSAGE----- de header en footer). Ik heb al 100 jaar geen php gecode maar dit zullen een paar regeltjes zijn.


3. De inhoud van de user post sanitizen en wegschrijven naar een bestand, en via passthru(pgp..) laten checken. Output in verify-boolean.


4. Aan de HTML in /posting/<postid> naast "Vandaag, Door Anoniem, 12:00" in tekst of kleurtje de output van de if-pgp en pgp-verifiy boleans verwerken. bijv. "Vandaag, Door Anoniem, 12:00 met PGP-VERIFIED".


5. Dit is in een uurtje in elkaar geklopt maar je wilt waarschijnlijk punt 3 voor snelheid bij het posten al doen en niet bij het opvragen / elke HTML request of F5 hoewel dat laatste veiliger is maar dat hangt af van hoe low traffic je forum is.


Dit is beter dan md5 of sha hashes. De user blijft anoniem. De key upload je 1x. De in weergave gestripte headers kun je in de HTML gewoon <!-- wegcommenten --> zodat zelfs de paranoide eindgebruiker nog manueel kan verifieren. Je bent niet afhankelijk van de integriteit van databases of moderators (want dan krijg je "Vandaag, Door Anoniem, 12:00 met PGP-FAILDED") en je forum krijgt bling bling... er is nog geen forum die dit doet terwijl het een simpel concept is.

Hashtags, tripcodes is uit lang vervlogen tijden. Daar moet je geen waarde aan hechten.

Misschien denkt de moderator hier wel, wat een cool projectje voor een winteravond. Een primeur voor deze site als toonbeeld van professionaliteit en security op forumgebied, als voorbeeld voor andere fora.

Zoals ik al zei was het op Usenet heel gebruikelijk maar op HTML forums worden de signatures niet op prijs gesteld want rommel. Heel stom want juist in HTML kun je makkelijk filteren met een "show/noshow" knop.

Het is maar een idee.

[1] https://www.quora.com/What-is-a-PGP-signature?share=1

Ik vraag mij af of dit een verkapte vorm is van "tracking-opties" verkopen (promoten) op deze site. Dan vraag ik mij af met wel doel in zicht.

Iemand die anoniem wenst te blijven zal echt geen hash aan zijn posts toevoegen want dan is het niet meer anoniem. Iemand die Tor gebruikt of een VPN zal door te gebruik te maken van zo'n hash juist minder anoniem zijn omdat je verifieerbare (=indirect herleidbare) informatie plaatst op internet.

Daarbij is ook deze methode niet bestand tegen manipulatie, zeker door mensen met toegang tot krachtige computers.

Dit zou alleen iets zijn voor die 4 individuen (JO, luntrus, #sockpuppet, Jodocus Oyevaar) die geen account hebben maar wel impersonatie willen tegengaan als alternatief voor een inlog. Het lijkt me een leuke gimmick (tevens trackingtool) voor alternatieve denkers.

Dan sluit je gewoon zo af:

Maar het was wel een creatief voorstel!


Gr. Piet md5 6046ed57b742d0dca8504cecd0c0b03b

Ik doe niks met 4chan, maar als ik https://www.4chan.org/faq#trip en "secure tripcode" daaronder goed begrijp, werken beide mechanismes anders. Maar dank voor de tip, het zou me niets verbazen als zoiets allang wordt toegepast!

Je kunt ook gewoon de keuzes van andere mensen respecteren. In plaats van dit soort gezeur.

Binnen 5 uur te kraken door mensen met een degelijke GPU.

https://www.betterbuys.com/estimating-password-cracking-times/assets/images/password_time_and_length.jpg

Leuk om te weten:

https://www.betterbuys.com/estimating-password-cracking-times/

De zwakheid in md5 hashes bijvoorbeeld is dat je in tegenstelling tot een wachtwoord (website login met a-z, A-Z en leestekens) beperkt bent tot 0-9 en a-f dus 16 combinaties maar wel 16^31 en dat is nog best veel.

Collusions zijn een zeer klein risico omdat een collusion achteruit in de tijd gaat en dus stopt (er worden forward hashes gegenereert in dit voorstel). En de kans dat een collusion ook net een md5 sum (hexdec 31 chars) is zeer klein.

Dan weet ik niet of je iets kunt met cryptonanalysis van iteraties van forward md5 sums die steeds op elkaar gebaseerd zijn, als je er veel van kunt verzamelen.

Misschien kan een cryptoloog hier wat meer over vertellen?

Ik zou het idee in elk geval niet gebruiken voor internet sites.

Beste Erik,

Ik vind het niet een heel gek idee, al is wel wat gedoe.
Maar het is misschien ook niet verkeerd om vooral voor anonieme posters een iets hoger drempeltje te leggen?
Wat dat betreft is het net als met email: hoe gemakkelijker en goedkoper het is, des te meer wordt er mee gespamd.

Dus elke anoniem die anoniem wil blijven maar wel wil aantonen dat zijn/haar eventuele vervolgposts (in dezelfde thread)
werkelijk van hem/haar zijn, zou van www.security.nl een zootje opeenvolgende SHA256-hashes moeten krijgen
(van een rij random bytes van voldoende lengte die door www.security.nl wordt gegenereerd)
om er mee te kunnen posten zoals jij voorstelt? (waarbij security.nl dus de SHA256-hash gaat vragen i.p.v. capcha)

Het blijft dan overigens wel mogelijk om na iedere post meteen weer een nieuw zootje hashes aan te vragen, zodat deze relatie tussen posts niet kan worden gelegd. Echter deze zijn gemiddeld genomen minder betrouwbaar,
want voor de wat serieuzere posters lijkt mij dat er niet echt reden is om bezwaar te hebben dat bepaalde posts in een thread aantoonbaar van dezelfde anoniem zijn.

In dit geval is de capcha dus alleen nog nodig voor de aanvraag van een nieuw rijtje SHA256 -hashes,
omdat zonder ingave van een ongebruikte uitgegeven SHA256-hash (die bovendien onderaan het bericht voor iedereen leesbaar en controleerbaar zal verschijnen), een bericht bijv. automatisch door www.security.nl genegeerd.

Ik zal hier, speciaal voor de kleine Fabeltjeskrant kijkbuiskinderen onder ons, iets uit de vroege begintijd van het Wilde westen op internet willen laten zien. Want zie hier, opgediept uit stoffige archieven van de Wikipedia:

https://en.wikipedia.org/wiki/Geek_Code

De bovenstaande GEEK-code block is hier getoond als een parodie op het wat meer bekende PGP-code block, dat in dit voorbeeld een leesbaar en "ondertekend" bericht bevat. De oplettende lezer hier zal hebben opgemerkt dat ik Robert A. Hayden's oorspronkelijke GEEK-code block voor dit doel opzettelijk heb verminkt, om het hele punt te illusteren.

De voorgestelde nick hashes hebben namelijk geen omvattend code block voor de tekst die er tussen staat. De echtheid van de uiting van de schrijver van het bericht valt dan, zeker bij gebrek aan een aan een account te koppelen public key, niet met zekerheid te verifieren. Maar goed, dat beseft Van Straten ook wel :-) Nu nog een goede uitwerking van het idee.

Het vervelende is dat je zo'n tekstbestand wel PER TOPIC moet bijhouden en dan nog gaat het de mist in als een
moderator besluit je bijdrage niet te accepteren.

Sommige van mijn collega's zouden hier best onder hun eigen naam of pseudoniem willen schrijven, alleen kunnen ze van hun inkomen helaas geen advocaat, kogelwerend vest en een 24/7 lijfwacht betalen. Bovendien, hun werkgever of detacheerder ziet het liever niet dat de hele buitenwereld weet waar ze in hun vrije tijd vertoeven.

Tot die tijd is het gebruik van een pseudoniem, met daarachter een ProtonMail.com account, alleen via Tor, misschien verstandiger om mee te beginnen. Ik houd het daarom voorlopig bij "Anoniem", zonder een opeenvolgende reeks hashes. Dat neemt niet weg dat ik het wel een goed idee vind.

Dank voor alle reacties, het wordt weer leuk en leerzaam op security.nl!

Ik probeer dit weekend op e.e.a. inhoudelijk te reageren, maar alvast een tip voor o.a. de Python coders: ik wist al dat je met Alt-255 (Alt ingedrukt houden en 255 tikken op je numerieke toetsenbord) een non-breaking space kon maken (zie onderaan http://ascii-table.com/ascii-extended-pc-list.php).

Omdat ik op dit moment bezig ben met een project waarvoor ik in andere charsets dan ASCII moest duiken, heb ik het e.e.a gelezen over UTF-8. Via-via kwam ik op het idee om eens in Wordpad.exe (W10) te kijken wat er gebeurt als je daar Alt-255 gebruuikt: dat gaat prima! Je kunt de ASCII sourcecode eenvoudig copy-pasten in Wordpad (en desgewenst regelafstand en lettertype aanpassen), en dan alle reeksen van (bijvoorbeeld) 4 spaties zoeken en vervangen door 4 maal Alt-255 (dan hoef je die combinatie maar 4 x in te tikken ;-).

Alsvoorbeeld een kopie van een stukje python hierboven, nu indented (maar ik weet niet zeker of alle regels, zoals 09, de juiste indent hebben):

Ik weet niet of bijv. Notepad++ ook met dit soort codes kan werken, zelf gebruik ik een eenvoudiger teksteditor en die kan het niet (Wordpad is -tot nu toe- echter op elk Windows systeem aanwezig).

Afkomstig van een ander ontspoort topic:

https://www.security.nl/posting/628127/Re%3A+Sudo+rechten+geven+en+schade+beperken


Het openbaar loggen van IP-adressen, zeker met bijbehorende webbrowser fingerprinting, is een bijzonder heet hangijzer. Dat hoef ik jou als superuser niet uit te leggen. Dat gaat hier echter niet werken, omdat veel van de anonieme bezoekers op Security>NL, zo vermoed ik, vanaf wisselende fysieke locaties werken of vaak Tor-exits, of zelfs I2P-routers met verborgen web-gateways, gebruiken. Hoe denk je die postings te traceren?

Zo'n opzet zou dan een grote brij van praktisch niet te traceren hash-IDs opleveren, waar voor de forum lezer geen enkel touw aan vast te knopen is. Dat temidden van een kritisch en technisch onderlegd forum publiek, dat toch al tot het gebruik van te veel afkortingen neigt. Vergeet het. Zo'n chaotische indruk schrikt zeker een breder publiek van geinteresseerden af.

Maar dan is het weer geen geldige Python-syntax.

Nee, dat klopt niet. Je kan de juiste indentatie oppakken door "Reageer met quote" te kiezen en vanuit de quote in het teksveld te kopiëren en te plakken. De spaties staan er op zich in, het is alleen dat ene ontbrekende regeltje in de stylesheet van security.nl dat het verknalt.

sha256:74bdc57548187b0a183620f50fec8ff7c6e51f2796f56b19298ba8bf8f2cadbd ;-)

Zeer handig en overal inzetbaar systeem met dank aan TS.

Handig ook voor emails, als je geen zin hebt om elke mail te signeren.

Handig voor ticketsystemen, om de consistentie en volgorde van berichten te toetsen.

Dit systeem kun je ook in gewone correspondentie toepassen. Het is maar 1 regel. Brieven op papier kun je niet signeren met PGP. Deze code kun je zelfs inkorten door de juiste hashfunctie te nemen en als Intern Kenmerk gebruiken bij correspondentie.

Een van de betere bijdragen op deze community in tijden.

Men zou in het Python script de reeks van gegenereerde hashes optioneel van een nickname, volgnummer en het gebruikte checksum algoritme kunnen voorzien, bijvoorbeeld in het volgende formaat:

Met een volgnummer kan bepaald worden dat een opeenvolgende anonieme posting, van dezelfde persoon of entiteit, uit de gegenereerde reeks van hashes mist, bijvoorbeeld vanwege een storing, een weigering van plaatsing of verwijdering door de redactie. Wat een logische verklaring kan zijn voor het falen van een checksum.

Dat past allemaal nog net op 1 regel in de venster breedte onder de Tor Browser. Een vast datum stempel er bij zetten wordt wel erg krap. Het seed moet natuurlijk wel geheim blijven, maar ik kan mij niet voorstellen dat iemand in zijn eentje op Security.NL meer dan 9999 opeenvolgende gehaste postings in één en hetzelfde topic wil gaan plaatsen. Hoewel?

Ik ben ook anoniem hoor.

Mijn eerste post op deze website.


@b88bf8144c60616ae29de39e0deba5279c10ee32edf797f108b0bb1aa1c26cae

Ik krijg de error:



Ik ben geen programmeur dus los ik anders op voor hetzelfde resultaat.
In 1 regeltje in bash:


dit genereert een output.txt met 20 opeenvolgende sha256 hashes gebaseerd op "wachtwoord"
en nog een regeltje voor een leesbaar format:


Wie mijn wachtwoord kraakt mag me een baan aanbieden ;)

Ik genereer er bijvoorbeeld 1000 offline en dan room ik af, die zet ik op de pc met internet toegang. Bij een hack heb je zo nog altijd de eerste sleutels.


Koos - sha256:ac6010ad37f676a8ec185fb48e8a5cbc77408f96dbaf81388f11f0d734495b75

Als je mijn volledige bijdrage had gepost dan had iedereen kunnen zien dat dit er zelfs al - relativerend - bij staat.

https://www.security.nl/posting/626870#posting628127

Een andere site weet natuurlijk niet welke inputs security.nl zou gebruiken en hoe die gecombineerd zouden worden. Desondanks blijft het inderdaad security by obscurity en - inderdaad - als de geanonimiseerde gegevens ooit op straat zouden komen te liggen, dan heb je de privacypoppen aan het dansen.

Voor een slechtziende of blinde, die werkt met een braille regel, valt een lopende discussie een stuk eenvoudiger te bevatten als je je in het vervolg bij het "quoten" beperkt, tot alleen de voor je betoog relevante tekst passages.Voor de wel goed zienden onder ons is dat te aanschouwen beeld dan vast ook een veel prettiger aanblik. Hartelijk dank :-))

1984 on steroids leuke tijden zijn het

Zijn er nog van die plaatsen waar dat je anoniem mag reageren Is het nog steeds niet goed

Moeten we echt overal gevolgd worden ?

Privacy en security concepten a.u.b. niet verwarren. Je houdt zo inderdaad een tracklog bij (misschien ook handig voor je eigen administratie). Het idee achter deze hash signature is dat je kunt bewijzen dat een post van jou is. Het maakt impersonatie alweer wat moeilijker, afhankelijk van wie je adversary is :)

Koos - sha256:4abd67d0d660ca3609122e04147423d3dbfa8987951550bff4045713e36d2cd5

Wel een punt. Met dit systeem moet je integriteit van berichten op fora met een korrel zout nemen. Bij elk forumpakket wat ik tot nu toe gezien heb kunnen moderatoren de inhoud van berichten (achteraf) aanpassen. Je moet dus maar op vertrouwen dat een moderator of systeembeheerder nooit corrupt zal worden. Het is natuurlijk geen PGP sig over je post.

Koos - sha256:804f969651a8e9ef78acc0b2d9bb5b92f26c81c33562bb5c444ff859516e4096

Volgens mij kan het een stuk eenvoudiger, zonder hash-gereken en minder werk:

Bijv. elke anoniem die wil reageren zou van security een unieke willekeurige string kunnen krijgen, die de anoniem lokaal onthoudt (bijv. opslaat met copy-paste). Deze string is een beperkte periode geldig (bijv. 3 maanden) voor alle topics,
en verschijnt voor security.nl-lezers niet in beeld, zodat alleen de betreffende anoniem en de server van security.nl de string kennen. Security.nl slaat deze string dus op, zodat legitieme uitgegeven strings kunnen worden terugherkend.

Is de geldigheidsperiode van een string verstreken, dan worden ze van de server gewist, en moet de anonieme poster gewoon weer even een nieuwe string opvragen en onthouden door deze lokaal op te slaan.
De oude string kan dan worden vergeten.
(Het doel van een geldigheidsduur is dat het aantal uitgegeven strings die de database vult op den duur niet uit de klauwen gaat lopen)

Het proces gaat dan verder als volgt:
1. een anoniem wil reageren, flanst zijn post in elkaar, vult de capcha in, en klikt op "reageren"
2. het systeem van security.nl herkent dat het geen geregistreerde gebruiker is (dus anoniem) en vraagt zijn unieke string.
3. de anoniem vult zijn unieke string in (copy-paste) en klikt ter bevestinging op een nieuwe knop "zend string" o.i.d.

4a. Vervolgens test nog te schrijven software op security.nl of het om een legitieme string gaat.
Zo niet, dan krijgt de gebruiker max. 3 kansen om de string opnieuw in te geven.
Na de derde keer wordt de post geweigerd en gewist en gaat men terug naar af.
4b. Blijkt de opgegeven string geldig, dan gaat de programmatuur op security.nl eerst na of deze anoniem al eerder had gereageerd in deze zelfde thread/topic. Het is hier de bedoeling dat op de security.nl server door de te ontwikkelen software per topic wordt bijgehouden welke anonieme "strings" er hebben gereageerd, door per topic hun unieke strings op te slaan samen met het aan hen toegekende anoniemvolgnummer. Aan elk topic/thread kleeft dus een databeesje van strings van anoniemen er hadden gereageerd, samen met het hun toegekende Anoniemvolgnummer in die topic/thread.

Per topic wordt de eerste anoniem die reageert automatisch "anoniem_"1 , de tweede (andere) anoniem_2, etc.
Er verschijnt dan bijv. in de grijze balk (die niet door gebruikers is te vervalsen): " Vandaag, 19:15 door Anoniem_3".
wanneer het gaat om de derde nieuwe anoniem die in dit topic had gereageerd.
Reageer deze anoniem later nog eens in hetzelfde topic, dan herkent de software die moet worden geschreven
dat je in deze thread al eens eerder had gereageerd, en dus "Anoniem_3" bent in deze topic/thread.

In dezelfde topic/thread blijf je dan dus steeds Anoniem_3 voor alle berichten die je in die thread post.
Maar reageer je in een andere thread, dan kan je daar bijv. best Anoniem_1 zijn, of Anoniem_12 of whatever.
Het hangt er maar vanaf de hoeveelste anoniem je daar bent.
En waarom zou je ook een anonieme auteur van een nieuw topic niet m.b.v. zijn string altijd "Anoniem_1" noemen,
zodat men ook zeker weet dat het echt "de maestro himself" is, die in een reactie het woord weer heeft.

Zo is er dus geen relatie te leggen tussen anoniemen in verschillende topics/threads, maar wél in 1 en dezelfde topic/thread! Dit komt de leesbaarheid ten goede, terwijl men trolgedrag van een bepaald hinderlijk type voorkomt,
omdat je je op deze manier niet in dezelfde thread voor een andere anoniem kunt uitgeven of die schijn kan wekken.

En wordt een post gelockt of verwijderd, dan kunnen alle anonieme strings die aan die post "kleven" automatisch worden gewist, en ook als de geldigheidsduur van een string voorbij is, kan deze string bij alle threads automatisch worden gewist. Wat blijft is ..... door Anoniem_1, ....... door Anoniem_2 etc., in de grijze balk boven resp. elke post.


Het is maar een alternatieve voorzet, variaties zijn natuurlijk mogelijk als dat wenselijker mocht zijn.

Je moet allereerst begrijpend leren lezen. Dan had je begrepen dat het juist om weglating van relevante delen uit een quote ging. Volledig quoten is een ander uiterste maar delen weglaten en dan gaan uitwijden over juist dat wat weggelaten is, dat is erger.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


Dat zou je ook nog kunnen doen. Een bericht aanmaken met een externe tool en dat signeren.
-----BEGIN PGP SIGNATURE-----

iQGtBAEBCgAXEBxTdXBlcnVzZXIgPG4vYT4FAl2r9QEACgkQqb1Q9bov/F1afAwA
oNt0ed3cwtfey+iM90SdJ5B85N8KaWEUJqrmx/XkRoyuP4kjXTg0P+WP0fbwEpRH
TjgXp4ufBGm3fQAXa6/c1IRp1XqYX1rF3MHUiroiMgAR8uLpajytBht/CU6lI+2/
oLwq7yF+FLhHoZovUhCkeRVDo+Y/rp/Gfp8c/ZWJlMszcuyJHO6rE5G5F8DIaxI7
et/mf2Vbt/zj+vN7KS1dvXjye41N7GcXYuP71miNCw80JrxV7rrFXPNeMtGxwwlr
U9IbXz1LkOMxJmGIfpNt2/+NDsaETFixwIWhst+3Yfa5YfDqzOv731k4S4aXfHmo
tnlRAjKg/Y+ej13oTzriJKU7ROeBWScsN6fzCS2/Lu2QrbX6m/8GLoX1MvhwD0Ci
CBznvgXixmMEW8tv66l3cmfTb1nsq0mC0W/38YiSgDL1qCEgd6w68jGbuj0lyOaX
f8bnoDJUUABGQqdvA8NpgJlWKk/JkF9rywFbqgEIpGNzGH5WmPjKadDnniPBRQJb
=JU+5
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Deze werkt prima onder Android:

https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain
-----BEGIN PGP SIGNATURE-----

iQGtBAEBCgAXEBxTdXBlcnVzZXIgPG4vYT4FAl2r9f4ACgkQqb1Q9bov/F0efAwA
pIYtokp2vhcdkhayANV++mRy3lAuSmnbv0JiyawVeeyY4tL22JrpnJAhpyMM6dDq
bJbXlBtJ1zOiBsO6GbumoCatxLYNwKzXd6cMKqGK0I8CixZwRQWe6VJJxUszX1Lk
yAtjt1EjXqUG/yhZSyO/qTStLk81zQzxUORZt0rHvSQNAmEl0VZ0CyFJEzU7cBJP
K//J/590o5oXSvrJOpE1Ie3Abv7Lnct81OZLU3s90t8efTj8P5B7NHVciHFPQ2Eu
cU/gQTi5ew+HNWZSbv1qBi7ynRXDfyqGxi9K9P8bbH8lJLZ3PL2k9OJztnTdKgvA
HDbKHGfe4a95MrTMLEDqdQCZCtCqPp+8pU4AZJ12QSOqB4VrnANM27LWbTKJCPmw
Vj9rwmbT7vn4TjEh6fGvscH+T1At2lPv7wdtxZNjUhcWgWVPh7vQzaQxkmnN9lFK
2nIstwi3Ex7XOjEXOz45NX/Is93GwLk3rzPSvlK47ymC85bzQZZn7ucorXBYN2RM
=ibNi
-----END PGP SIGNATURE-----

Leuke vorm van toegepaste cryptografie. De methode is bijna identiek aan de methode zoals beschreven door Philip Karn en Neil Haller op https://tucops.info/tucops3/hack/password/live/aoh_skey.htm en draagt de naam S/KEY. Zie https://en.wikipedia.org/wiki/S/KEY voor meer informatie.

Mijn excuses dat ik niet op alle reacties en/of volledig kan ingaan. Ik hoop op jullie begrip!

De redactie heeft, zo te zien, jouw verzoek opgevolgd, door toe te voegen: "white-space: pre-wrap;". Als gewrapte regels niet onwenselijk zijn, dan previewen en er rekening mee houden dat sommige webbrowsers iets grotere lettertypes kunnen gebruiken. Hartstikke fijn, dank ook aan de redactie!

Als je per thread een nieuwe sequence gebruikt (effectief hetzelfde als onderaan de lijst een waarde weggooien en met de waarde daarboven verder gaan, breaking the chain dus), lijkt mij de kans daarop klein. Veel eerder verwacht ik dat ML in toenemende mate schrijfstijl en meningen zal kunnen herkennen en aan een specifiek individu koppelen. Je hebt dan maar één of enkele versprekingen nodig om jouw volledige identiteit te kunnen vaststellen.

M.b.t. identiteit en opinie: gisteren las ik in https://www.nu.nl/weekend/6005078/waarom-laten-we-ons-niet-door-feiten-overtuigen-dat-ligt-aan-ons-brein.html een aardig artikel hierover. Voordat ik dat las was ik er 100% van overtuigd dat ik volledig opensta voor argumenten die mijn ongelijk bewijzen. Maar klopte die 100% wel? ;-)

Wat ik schreef was in dit kader enigszins off-topic, ik doelde hiermee vooral op de privacy-risico's die wij lopen doordat (vooral commerciële) partijen de AVG denken te kunnen omzeilen door bijv. MAC-adressen van getrackte smartphones (bijv. op de Wallen) te hashen. De beveiliging van mijn eigen router en smartphone heb ik grotendeels zelf in de hand.

Door een recente wijziging kan dat (helaas wat mij betreft) nog maar een half uurtje na de laatste wijziging. Als ik onzin uitkraam (dat gebeurt regelmatig) en iemand corrigeert mij (gelukkig gebeurt ook dat regelmatig) dan kan ik mijn oorspronkelijke bijdrage niet meer aanvullen met een correctie.

Een ander nadeel van anoniem posten is dat je jouw bijdragen nooit zelf kunt verwijderen, wat wel kon (ik weet niet of dat nog zo is) door je account op te heffen - als je dat hebt natuurlijk.

Krachtige computers helpen niet, want in principe moet je gemiddeld 2^255 (de helft van 2^256) berekeningen uitvoeren om, op basis van een SHA256 hashwaarde, de input te kunnen uitrekenen. In de praktijk is het altijd wat gunstiger voor aanvallers, dus laten we uitgaan van 2^240. Dat is ruim 10^72. Even een "losse pols" berekening, correct me if I'm wrong.

Stel dat die krachtige computer een picoseconde (10^-12 seconde) doet over een berekening. En laten we 1.000.000 van die computers parallel schakelen (geen geldgebrek dus). Dan duurt het 10^56 seconden om één input uit te rekenen. Als je rekent met 365 dagen in een jaar, zitten in zo'n jaar 31.536.000 seconden. Dan duurt die berekening ruim meer dan 10^48 jaar. Helaas gaan die computers niet zo lang mee, maar hoogstwaarschijnlijk hebben we, ruim voor die tijd verstreken is, veel snellere computers. Wanneer we computers zullen hebben die dit aankunnen weet ik niet - maar niemand verwacht ze de komende jaren. En mochten ze wel snel verschijnen, dan hebben we grotere problemen dan gekraakte hashes in berichten op security.nl.

Eens, daar ging ik ook van uit. Een leesbare nickname zodat anderen weten of meerdere posts, in elk geval binnen één thread, door dezelfde persoon geschreven zijn, en die hash om bedrog aan te kunnen tonen mocht iemand anders met jouw nickname "ondertekenen".

Dank je wel!

Als ik anoniem zou posten (dat heb ik wel eens gedaan), en hier gebruik van zou maken, zou ik dit volledige in eigen hand willen houden en niet aan security.nl willen overlaten.

Een van de redenen daarvoor is dat ik weinig vertrouwen heb ik CSPRNG's (Cryptographically Secure Random Number Generators). Te vaak bleken die dingen in het verleden niet goed te zijn ontworpen, verkeerd te zijn geïmplementeerd/gewijzigd, niet goed te werken (bijv. als gevolg van virtualisatie), een ingebouwde "predictability" backdoor te hebben, extern beïnvloedbaar te zijn of informatie te lekken (bijv. via side-channels).

Een andere reden is dat, als security.nl iets fout zou doen, mogelijk van alle bijdragen met hashes op deze site de (nog niet uitgegeven) parent-hashes uitgerekend kunnen worden. Wellicht ook geen enorme ramp, maar wel gezichtsverlies (het is ten slotte een security site :-)

Is dat echt zo'n probleem, d.w.z. als je je zorgen maakt over "anonieme identiteitsfraude"?

Daar heb je wel een goed punt. Als je een hash-regel niet weggooit uit het bestand, maar er "used" voor zet o.i.d., kun je die hergebruiken als een bijdrage niet wordt geplaatst. Echter, het valt me op dat sommige anonieme bijdragen later verschijnen (na moderatie te hebben doorstaan) dan andere, later geposte, bijdragen. Met andere woorden, je weet niet precies of en wanneer jouw bijdrage zal verschijnen, en kunt tot die tijd geen nieuwe bijdrage posten.

Kent iemand een oplossing voor dit probleem?

Dat klinkt meer als een soort tijdelijk account; ik vermoed dat de meeste anoniemen nou juist niet willen dat security.nl iets van hen onthoudt (anders dan reeds geposte bijdragen natuurlijk).

@Superuser en andere PGP-ers: PGP kan maar geeft een hoop "troep" onderin je posts. Het volgende kan ook:
(1) Gebruik de hashfile zoals ik bovenaan deze pagina beschrijf;
(2) Schrijf de bijdrage met onderaan: nickname sha256:hashvalue en leg uit dat de VOLGENDE hash niet moet worden meegenomen in de HMAC-berekening die ik hieronder beschrijf;
(3) Druk "Preview";
(4) Kopieer naar klembord;
(5) Plak in een (nog te maken) tool die alle white space verwijdert en m.b.v. een HMAC functie, met als secret de parent-hash, een "message authentication code" van jouw bijdrage berekent;
(6) Druk "Aanpassen";
(7) Plak het resultaat van de HMAC functie achter nickname sha256:hashvalue of zet deze op een nieuwe regel.

Nadat je de parent-hash publiceert, zou een security.nl beheerder jouw eerdere bijdrage kunnen wijzigen en de MAC aanpassen. Maar dat is wat ver gezocht denk ik. Voor de zekerheid kun je de pagina natuurlijk door archive.org en/of archive.is laten archiveren (voordat je de parent-hash publiceert), zodat je aan de hand van die sites kunt bewijzen dat jouw bijdrage is gewijzigd.

Ah, dat lijkt inderdaad als twee druppels water! Ik had al een voorgevoel dat ik hier geen miljonair mee zou worden en heb het algoritme daarom maar niet voor mezelf gehouden... ;-)
Ik wist niet dat deze methode ergens beschreven was - maar credits where credits are due!

Wel eens van PGP gehoord?

Ja (zie o.a. https://security.nl/posting/39614/).

Wedervraag: waarom lees je niet eerst alle reacties (zoek anders op z'n minst even naar PGP in deze pagina) voordat je wat roept?

(Overigens slim om dit niet-niet-anoniem te doen, anders weten we wie we niet meer serieus hoeven te nemen).

Privacy Policy >> Gegevens inzien, correctie en verwijdering

https://www.security.nl/privacy?version=2018

Security.NL behoudt zich het recht voor deze privacy policy aan te passen. Wijzigingen zullen op deze website worden gepubliceerd.

Ah! Jouw reactie zag ik eerder dan het resultaat ervan omdat ik van onder naar boven keek of er nog iets interessants was gemeld ;-)

@REDACTIE: Hartelijk dank!

Voor kopiëren en plakken zou dat geen probleem moeten zijn. Previewen is trouwens sowieso aan te bevelen, het is namelijk maar al te makkelijk om typfoutjes te maken in bbcodes.

Ik vind het hoe dan ook wel een goede gewoonte om regels niet te lang te laten worden in code. Ik heb 79 tekens ingesteld staan in mijn editor. Dat is vermoedelijk een waarde die niet snel tot problemen zal leiden bij het uitwisselen van code. Voor mijzelf is het een goede waarde om met een voor mij prettige fontgrootte op een doorsnee beeldscherm twee sources naast elkaar te kunnen zetten.

Maar over dit soort voorkeuren worden loopgravenoorlogen gevoerd, ik benadruk dus dat het niet meer dan mijn voorkeur is en geen voorschrift (en voor wie nu met PEP-8 aan komt zetten: ook dat is geen voorschrijft, het is een richtlijn ;-) ).

sha256:972f39f1b1282954adb0607d310c77cbb37669d368a07c51bf9f23057a552554

Wat een nuttige bijdrage. Voor inhoudelijke reacties m.b.t. PGP, waar mensen wat aan hebben, zie boven.

Hm. Het is _heel_ glad ijs om uit de losse pols een crypto protocol aanpassing te suggereren, maar laat ik een gooi doen.
(als anoniem, dus ik heb geen reputatie hoog te houden ...)

Je zou een sequence nummer (van postings) bij je hash kunnen plaatsen, en hangende het moderatie tijdswindow gewoon een paar voorgaande hashes van postings die je al ingediend had maar nog niet doorgekomen zijn erbij kunnen zetten.

Dan is ook zichtbaar dat je claimt meerdere bijdragen gepost te hebben - als moderatie er een dropt uit de serie is dat te zien - (nee, helpt niet tegen malicious moderator die je hash lijst inlkort en de volgorde opeenvolgend houdt. ).

Misschien is CRC32 makkelijker. Dat zijn maar 8 karakters. Met die lange hashes wordt het een rommeltje.

Minder rommelig zeker, makkelijker weet ik niet. Maar totaal zinloos, want CRC32 kraak je binnen no time. CRC32 is dan ook geen cryptografische hash, maar prima voor het met behoorlijke zekerheid detecteren van onopzettelijke wijzigingen.
Nb. die betrouwbaarheid is alleen redelijk als dergelijke onopzettelijke wijzigingen zelden voorkomen.

???
Aangezien met jouw methode iedereen kan zien welke berichten van dezelfde anoniem zijn, kan security.nl dit ook zien,
en het eveneens misbruiken als ze dat zouden willen.
(sha256 hashes hangen aan posts, die weer in de database staan bij security.nl....)
Maakt dus weinig uit.

Verder zie ik security.nl er niet voor aan dat ze zich voor iemand anders zullen uitgeven door met de string van een ander aan de haal te gaan. Dan zouden ze zichzelf ongeloofwaardig maken.
Een laatste mogelijkheid is dat er eens strings van de site worden gestolen met een hack, of op de site wordt geklooid.
Maar hoe vaak komt dat voor, en hoe erg is dit dan eigenlijk? Waarschijnlijk niet meer dan vervelend.
De bedoeling is immers dat strings na bijv. 3 maanden automatisch worden gewist,
dus strings ouder dan 3 maanden staan niet meer op de site.

Overigens staat het in mijn voorstel anoniemen vrij om op elk moment een nieuwe string aan te vragen.
De anoniem bepaalt dus zelf wanneer hij relatie met zijn eerdere post(s) wil leggen en wanneer niet.
Misschien is het handig dat de anonieme poster zelf kan aangeven wat voor string hij wil:
- geen, gewoon ouderwets posten zoals het nu is. (geen relatie tussen posts)
- voor 1 topic (om kenbaar te maken welke posts van dezelfde anoniem zijn in één thread)
- voor een bepaalde tijd, bijv. max. 3 maanden (een soort tijdelijk account, maar dan anoniem (= zonder email-adres) )

(ik denk dat opgeven van emailadres meestal de reden is dat anoniemen geen account nemen...)


vr.gr.,
Anoniem 19-10-2019, 22:34

PGP sigs geven veel overhead. Een serverside implementatie (filter en verificatie check) is dan de oplossing. Dit is de ideale situatie.

De sha256 sig vertrouwt op de integriteit van de moderator (die immers achteraf content kan wijzigen) en het beschermt ook niet tegen een hack van server/client. Deze sig geeft enkel de mogelijkheid om je bijdragen te tracken en biedt slechts een basisbescherming tegen online impersonatie. Het is een leuk experiment.

1 regeltje tekst is niet zo erg als een rommelige PGP sig. Je kunt ook refereren aan een @hash als je op een bericht reageert in plaats van een naam en/of tijdstip als je niet wilt quoten.

Koos - sha256:f096ef9a939eb1eefc77363383e19d8906f10d47f1f26e98d7d10246b2367a41

Dit is inderdaad glad ijs, maar de zaak achter dit forum, de firma The Security Council B.V, gaat niet over één nacht ijs.


Anoniem op 18-10-2019, 19:19 stelde een eenduidige eenregelige nickname formatering voor, met daarin een serie dubbele punten als field delimiters, en volgnummers voor de postings. Zoiets als dit:


Zonder een eenduidig formaat wordt het nog een heel gedoe om de opeenvolgende hashes terug vinden, zeker als die ook nog verspreid staan over meerdere topics. De moderatie tijdsduur en eventuele afwijzingen zijn ook problematisch. Het zou betekenen dat hashes nog niet van de lijst kunnen worden geschrapt, terwijl die al uit handen zijn gegeven.

De hash in dit voorstel omvat de inhoud van het bericht niet, waardoor er met de inhoud kan worden geknoeid. Dat lijkt mij geen zuivere koffie. Kortom, zo'n losse hash bewijst weinig tot niets, terwijl de anonimiteit van de auteurs er mee te grabbel wordt gegooid. Men moet dus iets beters bedenken om de gemoederen op dit forum in toom te houden.

Daar heb je gelijk in. Ik heb jouw vorige (19-10-2019, 22:34) en de laatste bijdrage nog eens goed gelezen, en inderdaad kan denk ik wat je voorstelt. Er moet echter wel flink voor geprogrammeerd worden om te onthouden welke reeksen unieke karakterreeksen aan de vele anoniemen zijn uitgegeven, en welke na 3 maanden kunnen vervallen.

Ik denk ook niet dat de methode die ik bovenaan deze pagina beschreef aan zal slaan, laat staan een lang leven beschoren is. Maar het ging dan ook meer om het idee.

Over ideeën gesproken: mijn "signing" idee uit https://security.nl/posting/628112#posting628387 breng ik, iets aangepast, in de praktijk. Je kunt controleren of dit bericht niet is gewijzigd (inclusief opmaak) sinds ik het plaatste, als volgt:
(1) Download "rehash.exe" uit https://sourceforge.net/projects/rehash-2/files/win32/ (dit programma is geschreven door Dominik Reichl, de auteur van KeePass);
(2) Controleer dat het om hetzelfde bestand gaat als in https://www.virustotal.com/gui/file/cbf8ad544adfcf1f66123331bcb44a5132ddfefdfdceef11ff3ba41a315151e5/detection;
(3) Klik op "Reageer met quote" voor dit bericht;
(4) Selecteer alle tekst (inclusief bbcodes dus) TOT de onderste regel die begint met "HMAC";
(5) Kopieer en plak de tekst in Windows Notepad/Kladblok en sla op in een bestand genaamd test.txt (de tekst moet eindigen op 1178 en NIET op een lege regel, en het bestand moet precies 2770 bytes lang zijn);
(6) Voer uit (het commando met parameters in de volgende vette tekst moet op 1 regel staan):

rehash -hmac:d60606f7d0d4aa5dfb9b1b4514fb1bcf -n -sha256 -out:nospaces -out:lowhex test.txt

Nb. De secret key "d60606f7d0d4aa5dfb9b1b4514fb1bcf" bevat de eerste 16 bytes van de derde SHA256 karakterreeks bovenaan deze pagina, waarbij we even doen alsof ik die nog niet heb gepubliceerd; en de 4e karakterreeks zet ik in deze bijdrage.

Het resultaat van bovenstaande opdracht moet identiek zijn aan de HMAC-waarde onderaan dit bericht (zo niet, dan is er iets in het bericht gewijzigd sinds ik het plaatste). Indien je zelf constateert dat de redactie (of een hacker) iets aan jouw bericht gewijzigd heeft, dan post je de eerstvolgende hash (in dit voorbeeld de derde regel) gewoon niet. Lezers van security.nl kunnen dan wel zien (aan de hash achter de dubbele punt) dat het jouw laatste reactie was in een reeks, maar ook zij kunnen niet vaststellen dat die laatste reactie volledig van jouw hand is.

Erik:0001:e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178
HMAC: df2e9eaf1aca94f7ef558f7722817af11ab593eaa666f8c6b9dddf4659c281d1

Aanvulling: ik moest de HMAC-waarde onderaan bovenstaand bericht nog even editten omdat ik vergeten was dat, als je op "Reageer met quote" klikt, het bericht wordt aangepast. Als je een bericht van mij quote, wordt natuurlijk vooraan gezet:

[ quote ][ i ]Door Erik van Straten:[ /i ]_

(zonder de Alt-0255 spaties tussen de bakhaken die ik moest toevoegen om uitvoering van de bbcodes te voorkomen, en _ wordt een spatie).

In de HMAC berekening hierboven (en grootte van de file test.txt, zijnde 2770 bytes), heb ik er rekening mee gehouden dat genoemde karakterreeks ervoor wordt geplaatst (wat achteraan geplakt wordt boeit niet, omdat de onderste regel niet wordt meegenomen in de HMAC-berekening).

P.S. mocht de Redactie of een hacker mijn "signed" bericht wijzigen en de key en/of HMAC aanpassen, dan kun je in https://web.archive.org/web/20191021212527/https://www.security.nl/posting/628112/crypto+bewijs%3A+dezelfde+anoniem zien wat deze zojuist waren... ;-)

Een nog mooiere berekening is van de hand van Bruce Schneier, zie https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html, vanaf "Or read what I wrote about symmetric..."
Heel in het kort: hij maakt een berekening hoeveel energie er nodig is om de eenvoudigste teller te laten tellen van 1 tot 2^192, dat6 is 32 jaar alle energie van de zon. En dan gaan we uit van een teller met de kleinst mogelijke energieverbruik, gebaseerd op natuurkundige wetten.

En 2^192 klinkt al heel wat, maar het betekent dat je nog 2^63 zonnen (!!!) nodig hebt om tot halverwege 2^256 te komen. Bij een schatting van 400 miljard sterren (ongeveer 2^39) in ons melkwegstelsel heb je dan 2^22 melkwegstelsels nodig. Kortom, encryptie met een 256bit sleutel is niet met alleen brute force te kraken

Q

Je hebt me aan het denken gezet. De belangrijkste reden om anoniem te posten was het gemak.

Ik zie alleen steeds vaker anonieme posts "zonder inhoud", dat wil zeggen dat er of zonder onderbouwing "ik vind xyz" verkondigd wordt, of dat er zaken herhaald worden (in deze threat: "doe maar PGP"), of posts waarbij duidelijk is dat de poster alleen maar meningen van anderen na-papagaait. Terwijl er wel zinnige en interessante posts zijn die ik niet wil missen.

Dus de vraag die ik mezelf stelde was: wat zou ik graag zien?
Het antwoord was simpel: dat ik zie WIE de post gemaakt heeft zodat ik (anonieme) trollen kan negeren. Maar dan moet ikzelf ook "herkenbaar" zijn. De door jou voorgestelde oplossing is mogelijk maar vind ik te lastig, dus vanaf nu dan maar met een geregistreerd account :-)

Q

@Q1: dank voor de link naar het artikel van Bruce Scneier, en nogmaals/meer welkom op deze site!

Die software is alleen voor Windows. Klopt het dat je een andere HMAC-uitkomst krijgt bij gebruik van deze site: https://www.freeformatter.com/hmac-generator.html, of doe ik iets fout?

Nee, je doet niets fout. Op die site krijg ik echter weer andere resultaten dan op https://www.liavaag.org/English/SHA-Generator/HMAC/, geen idee waarom.

Opmerkelijk: de SHA256-HMAC van de tekst "test" met key "test" (alles zonder die aanhalingstekens) uitreken levert op beide sites 88cd2108b5347d973cf39cdf9053d7dd42704876d8c9a9bd8e2d168259d3ddf7 als resultaat op, en als ik "test" in een bestandje test.txt zet (zonder "regeleinde", het bestandje is dus 4 bytes lang), en uitvoer:
Hetzelfde resultaat dus. Ik vermoed dat er in de invoervelden van eerdergenoemde sites iets misgaat bij het kopiëren van wat "ingewikkelde" tekst (op de tweede site heb ik ook nog hex geprobeerd, na de tekst met een hexeditor in hex-bytes te hebben omgezet, maar dat werkte niet goed; ik kreeg als resultaat "String of HEX type must be in byte increments" terwijl het echt een reeks bytes is, maar wellicht een te lange).

Een aloud probleem is dat Windows (na MS-DOS) als regeleinde <CR><LF> (Carriage Return, Line Feed, de ASCII waardes 13 en 10) gebruikt, waar Linux standaard alleen <LF> gebruikt. Ik heb voor <CR><LF> gekozen omdat ik meestal Windows gebruik. Als je de tekst onder Linux opslaat, wordt het bestand daardoor 2751 bytes lang (i.p.v. 2770).

In principe zou je onder Linux de tekst met een "unix2dos"-achtig tooltje (https://linux.die.net/man/1/unix2dos) moeten kunnen omzetten, en zou een Linux versie van "rehash" dezelfde HMAC waarde moeten opleveren. Nb. rehash zou ook onder Linux zou moeten compileren en werken, de source staat ook op SourceForge en voor meer info zie https://www.dominik-reichl.de/software.html#rehash (het HMAC algoritme en de waarde van de gebruikte padding bytes worden o.a. beschreven in https://en.wikipedia.org/wiki/HMAC).

De reden om zelf geen online tool te gebruiken, is dat het -in de basis- niet verstandig is om secret keys op vreemde sites "te lekken" (ook de initieële random waarde en de hashes kun je natuurlijk het beste op een vertrouwd systeem genereren).

Om CRLF-, alleen LF- (Linux) en alleen CR- (MacOS) problemen te voorkomen, specificeert https://tools.ietf.org/html/rfc4880 voor OpenPGP overigens ook dat <CR><LF> moet worden gebruikt. Of die keuze, en die van mij hierboven, "de juiste" is, is natuurlijk discutabel. In elk geval kan ik zelf vaststellen of mijn tekst gewijzigd is, en iemand met identieke tools (of die wat extra moeite doet) zou dat ook moeten kunnen.

Anyway, signeren heeft wat meer voeten in de aarde dan slechts hashes van hashes berekenen, dus ook dit zie ik in de praktijk niet worden toegepast op deze site...

Beste Erik van Straten,

Maar de bank doet het wel met een ten naam stelling en het bijbehorende IBANnummer.
Jje krijgt als het goed is een groene tag te zien.
Handig ter controle, maar wordt dit ook opgeslagen en is zulke info daarna veilig tegen lekken?

Neen er volgt bij mijn naam geen QR code of Blockchain code, te link.
Men maakt toch niets over naar mij ;)

Jodocus Oyevaer (uniek individu)

Nu heb je het alleen nog maar over "gewoon Nederlandse ASCII". Ik ben betrokken geweest bij het signen van berichtenverkeer, waarbij zowel ASCII en EBCDIC, met verschillende code pages, en UTF-8 waren betrokken. En dat op Windows, Linux, Tandem en IBM systemen.
De enige eginsinds betrouwbare manier is om voor het berekenen van de hash de tekst consequent naar UTF-8 te zetten en te versturen (en bij ontvangst eerst de hash te berekenen voordat je de UTF-8 terug vertaalt naar de native karakterset op het ontvangende systeem.
Maar ook daar ontstaan problemen, bv. als een karakter uit de bron niet in het doelsysteem kan worden weergegeven. Denk aan dingen als "Jürgen" wat in simpele systemen omgezet wordt naar "Juergen". Een bericht van systeem A met daarin "Jürgen" komt op systeem B aan als "Juergen". Het bericht terug naar A bevat dan misschien wel de juiste hash, maar op systeem A lijkt het om twee verschillende personen te gaan. Er is nl. geen eenduidige manier om dat terug te zetten (van "Juergen" naar "Jürgen"), terwijl je dat als mens wel kan....

Crypto: het lijkt zo simpel, maar de pret begint pas in de praktijk :-)

Q

Daar ergens zal vermoedelijk het verschil wel zitten.
Overigens is mijn text-file 2753 bytes lang (2754 bytes als ik ook nog de LF tussen de 2 laatste 2 regels meeneem)

Je bent dus afhankelijk van welke format je texteditor gebruikt,
en ook nog zoals Q1 aangaf van de gebruikte karakterset.
Zo wordt het toch nog complex.

vr.gr.

Ik weet niet precies wat je bedoelt (bij mijn bank heb ik dat nog niet gezien), maar als ik je goed begrijp bedoel je dat jouw bank kennelijk een database heeft waarin de relatie tussen naam en rekeningnummer is opgenomen (die kant op, de andere kant op, of beide kanten op), waarvan gebruik gemaakt wordt om je te waarschuwen als je denkt geld over te maken naar Bob, maar Mallory jou op de mouw heeft gespeld dat Bob net een nieuw bankrekeningnummer heeft (dat van Mallory zelf of van een geldezel).

Informatie die gebruikt moet kunnen worden, is nooit 100% veilig tegen lekken. Echter, elk nadeel heb z'n voordeel.

Jouw bank kan het "verkrijgers" van data uit een onverhoopt lek wel moeilijker maken door niet de (privacygevoelige) informatie zelf, maar afgeleiden daarvan op te slaan (zoals zowel de hash van de naam als de hash van het bijbehorende bankrekeningnummer). Het probleem daarbij is dat bankrekeningnummers en korte achternamen weinig entropie hebben, waardoor brute force attacks en zoektabellen mogelijk zijn, en voor achternamen ook nog eens dictionary attacks voor de hand liggen.

Het beste (voor zover ik weet) wat je daartegen kunt doen is het creeëren van een soort "inbraakvertraging" door een protocol als Argon2 toe te passen (zoals ik eerder in https://security.nl/posting/628112#posting628142 schreef). Een nadeel daarvan is dat, hoe groter de inbraakvertraging, hoe meer geld (tijd, geheugen, CPU-cycles en energie) het de bank kost.

Je kunt vervolgens stellen dat, afhankelijk van hoeveel (tijd en/of geld) een aanvaller er voor over heeft, die "versleuteling" kraakbaar is of niet.

@Q1 (AKA Q): uit de grafiek rechtsboven in https://en.wikipedia.org/wiki/UTF-8, met hoe vaak bepaalde encodings werden gebruikt in de afgelopen jaren, blijkt dat jij niet meer de enige bent met een voorkeur voor UTF-8 ;-)

Wederom een vraag, kan aan de hand van de anonieme posting in combinatie met de ingevoerde verificatiecode
achterhaald worden wie de anoniem is die post aan de hand van IP van poster samen met de ingevulde code?

M.i. moet de moderatie dat kunnen zien, of de overheid dit kunnen opvragen bij de provider.

Vraag is in hoeverre is men nog anoniem op Interwebz, uitzonderingen dan daargelaten,

luntrus

Het is niet het enige verschil. Volgens de DOS-conventie is CR+LF een regelscheiding en volgens de *nix-conventie is LF een regeleinde. De consequentie is dat een DOS-tekstbestand niet eindigt in CR+LF en een *nix-tekstbestand wel in LF, ook de laatste regel heeft daar een expliciet einde. De *nix-conventie is bewust zo gekozen omdat dan met het cat-commando (en soortgelijke verwerkingen) tekstbestanden aan elkaar kunnen worden geplakt zonder dat de laatste regel van het ene bestand en de eerste van het volgende op dezelfde regel worden samengevoegd.

En er speelt nog een verschil: in de Microsoft-wereld is het gangbaar (voor teksteditors etc.) om een tekstbestand te laten beginnen met een byte order mark of BOM. Dat was oorspronkelijk het unicode-teken voor ZERO WIDTH NON-BREAKING SPACE, een teken dat visueel geen verschil maakt dus. De gebruikte unicode-codering (UTF8, 16-bit little of big endian etc.) is eraan te herkennen, dus is het geschikt als "magic number" voor unicode-tekstbestanden. Het geeft regelmatig problemen bij bijvoorbeeld CSV- en JSON-bestanden, waar het niet in thuishoort maar waar het wel door allerlei software aan wordt toegevoegd. Je suggereerde het gebruik van notepad, en dat voegt een BOM toe.

Beide verschillen beïnvloeden de hash-waarde. Lang niet elke tekst-editor ondersteunt en respecteert de verschillende conventies, en het is een behoorlijk geneuzel om het goed te krijgen als je editor het ondersteunt. Het is voorspelbaar dat daar heel wat fouten mee gemaakt zouden gaan worden. Om jouw idee goed werkend te krijgen heb je vermoedelijk een programma nodig dat het hele bericht qua regeleinden en BOM standaardiseert en op het resultaat daarvan de hash- en hmac-berekeningen uitvoert. Een interface die via het clipboard werkt zou in een GUI-context dan toegevoegde waarde hebben, zodat editors en tijdelijike bestanden overgeslagen kunnen worden.

Ja want het is ondanks de ondertekening van Koos niemand opgevallen dat ik in mijn laatste antwoord zijn tekst in de quote had veranderd. Of het is wel opgevallen maar omdat het topic ondertussen gelockt is kwam er geen antwoord?

https://www.security.nl/posting/627962#posting628557

@Anoniem 23-10-2019, 13:42 (naar verluidt luntrus): je bent nooit anoniem op Internet (afhankelijk van de trucs die je gebruikt, kun je het mensen, die jouw echte identiteit proberen te achterhalen, wel meer of minder moeilijk maken).

Je hebt gelijk dat de gebruikte codering o.a. afhankelijk is van de gebruikte teksteditor. en die BOM heb ik vaak eerder gezien. Tot mijn verbazing kreeg ik die BOM niet meer gegenereerd met Notepad onder W10 v1903, deze lijkt nu UTF-8 of zo te gebruiken (ik heb dit niet precies vastgesteld).

Die versie van notepad genereert voor de karakters á en à nu DE ENE KEER elk 1 byte (resp. 0xE1 en 0xE0) en DE ANDERE KEER 2 bytes (resp. 0xC3A1 en 0xC3A0). Ik begrijp nog niet wat de criteria zijn voor deze keuze, maar in elk geval maken dat soort verschillen digitale handtekeningen natuurlijk kansloos (niet alleen ik liep er tegenaan bij 0xC3A1 vs. 0xE1 voor á, zie https://stackoverflow.com/questions/26390313/get-non-ascii-character-from-single-character-code).

Fix: uitsluitend ASCII 32 t/m 126 gebruiken? Of in BASE64 posten? Beide worden geen succes wordt vermoed ik...

@Daemon: het was me wel opgevallen dat je jouw nickname hebt veranderd ;-)

Aaai, heb ik meerdere wijzigingen tegelijkertijd doorgevoerd? Dat is altijd een risico.

Zie wikipedia: https://en.wikipedia.org/wiki/UTF-8

Ofwel: afhankelijk van de UTF-8 BOM interpreteert notepad de tekst en gebruikt de betreffende codering. Zet het maar in een tekstfiletje, en voeg daarna met een HEX editor de UTF-8 BOM als eerste karakters toe. Ineens een heel andere letterset :-)

Dat was waar ik ondermeer in een eerdere post naar verwees: een tekst met de letter "á" gecodeerd met "0xE1" en dezelfde tekst met "0xC3A1" ziet er voor een gebruiker echt identiek uit maar de hash is echt verschillend.

(en ja, hier heb ik me eens volledig suf op gestaard: een text compare gaf aan identiek, de hash was verschillend, en ja, een binary compare was verschillend. Je ziet het pas in een binary/hex editor)
:-)


Q

allemaal leuk een aardig, maar als ik een hash kan aflezen van iemand; dan heb ik de volgende hash die hij/zij gaat gebruiken eenvoudig gevonden door slechts te hashen en dat stelt mij in staat als die persoon te posten. die hash bewijst mij dus helemaal niets op die manier.

Goh ik krijg opeens een idee....Als je nu eens laten we zeggen 10 hashes genereert (hash van hash van hash enz.)
en bij de eerste post vermeld je de tiende hash, bij een volgende post de negende hash. (iemand kan zien dat de hash van de negende hash als resultaat de tiende has oplevert, dus het is van dezelfde persoon) enzovoorts.
Want een hash van een hash berekenen kan iedereen,
maar een hash terugrekenen niet. Want dat is nu net het kenmerk van een hash.

(ho wacht... wat zei die Erik ook alweer?)

Klopt, daarom is het de bedoeling is dat je steeds de vorige (i.p.v. de volgende) hash post.

Inderdaad.. question everything...(Russia Today)

Goed lezen wat Erik schrijft. Het gaat niet om de volgende maar vorige hashes..

Dat systeem is goed genoeg tenzij je de NSA of Moscow als tegenstander hebt die met supercomputers terugwaartse hashes kunnen berekenen. Die kans is klein want je moet de precieze hash vinden en geen collision in een ander stringformat.

"Question Everything"

Ik blijf liever anoniem, anders had ik dit wel onder een account gepost.

Verstandige keuze, want nu weten we niet wie we uit moeten lachen voor het intrappen van deze open deur.

#metoo

Even een idee:
In je voorstel propageer je een methode om bij anonieme posts wel te kunnen zien of posts bij elkaar horen (van dezelfde poster zijn). Ik postte ook veelal anoniem omdat dat zo makkelijk is, terwijl ik wel de meerwaarde zie van posts waar ik de auteur van weet.
Het was voor mij de aanleiding om na te denken over anonieme posts: het is erg laagdrempelig, met als gevolg dat ze ook regelmatig best irrelevant zijn. Daarom lees ik liever posts van mensen "met naam": dan weet ik van te voren of het de moeite waard is om te lezen. Het mag anoniem zijn in de zin van dat ik niet weet WIE het is, maar wel of het steeds dezelfde is, ofwel een nickname mag ook (doe ik ook). Bovengenoemd systeem leek daar een voorzet toe.

Een andere benadering (dan de door Erik genoemde signing) is het stimuleren van niet-anonieme gebruikers, door geregistreerde gebruikers iets extra te geven. Ik denk bv. aan een "like" achtige functie, en dan bv. een tellertje met "Eens" of "Informatief", waar je als geregistreerde gebruiker op kan klikken. Dan komen interessante posts eerder naar voren, zowel anonieme als van geregistreerde gebruikers. Je krijgt dan inzicht in de kwaliteit van antwoorden van geregistreerde gebruikers, maar wordt ook gewezen op interessante posts van anonieme gebruikers. Op die manier kan ik mijn tijd op dit forum efficiënter gebruiken.

Wat vinden jullie hiervan?

@Q1,

Een levensvatbaar idee! Ik ben weer niet iemand die heel diep gaat nadenken over de eventuele voordelen of nadelen. Maar waar ik geen voorstander van ben is een mogelijkheid om 'dislike posts' chronologisch lager in de rij te paatsen. Een onderscheid zoals op eBay waar je een knop hebt om hetzij alle positieve, ofwel negatieve, danwel neutrale beoordelingen op te roepen is dan weer wel zinnig.

Mijn motivatie om dit een aardig idee te vinden ligt ook in het feit dat ik niet meer reageer op anonieme posts zeker als zij in mijn visie nogal ehh... negatief zijn. Een andere reden is dat in een lopende discussie het best mogelijk is dat je op twee anoniemen reageert in de veronderstelling dat het dezelfde persoon is. Trolgedrag vermijd en negeer ik op die manier.

Ik vraag me toch sterk af wat het probleem is dat door de voorgestelde cryptografische technieken moet worden opgelost want is er, buiten een gefrustreerde enkeling, überhaupt een probleen met anonieme reacties?
Security.nl staat toe dat anoniem gereageerd kan worden en deze reacties worden pas geplaatst als deze ontopic zijn. Als Security.nl alleen reacties met account zou toestaan zou dat inmiddels in effect zijn geweest.
Het is niet verplicht om Security.nl te bezoeken. Als je niet met anonieme reacties kan leven dan staat niets je in de weg om een eigen Security website te beginnen waar je alleen met "the chosen ones" kunt communiceren.

En ja, sommige reacties zijn behoorlijk off-topic of zelfs vervuilend (zeker die onzinnige Linux vs. Windows discussies) maar dat zijn ook veel reacties van accounthouders, want daar zit namelijk geen moderatie op wanneer deze geplaatst worden. Het is maar hoe druk je jezelf wilt maken of hoe kort je lontje is.
Daar kun je overigens ook hulp bij vragen om daarmee te leren omgaan.

Triest, dit soort posts. Geen enkel respect voor de keuze van je medegebruikers. Jij bepaalt of jij anoniem post, ik bepaal of ik anoniem post.

Kennelijk vindt de redactie van security.nl het ook geen probleem, want anders zouden ze anoniem reageren wel uitschakelen. Wie ben jij, om dit gedonder te noemen, en andere bezoekers te vertellen wat ze moeten doen ?

Ben je het er niet mee eens, mail de redactie.

@Anoniemen vandaag 11:43, 14:37 en 14:41: ik schrijf nergens dat ik geen anonieme bijdragen wil (sterker, ik post zelf ook wel eens anoniem).

Het enige dat ik, als gedachtenspinsel, beschreef was een systeem waarbij een anonieme bijdrager, desgewenst, zelf kan aantonen dat 2 of meer bijdragen van zijn of haar hand zijn zonder zijn of haar identiteit prijs te geven. Dat zou in het belang van de lezers kunnen zijn, maar ook in het belang van de betreffende anoniem zelf (niet alleen op security.nl, maar wellicht ook handig voor klokkenluiders, dissidenten, tipgevers en journalisten). Op security.nl o.a om te voorkomen dat je met een andere anoniem wordt verward - bijvoorbeeld omdat je net zo dyslectisch bent als een andere Anoniem, er een vergelijkbare schrijfstijl op nahoudt, en/of ergens ogenschijnlijk hetzelfde -maar op details ander- standpunt inneemt (bijvoorbeeld openlijk anti-Microsoft bent, maar *BSD prefereert boven Linux).

Kortom, er moet niks, wat ik voorstelde is volstrekt vrijblijvend (zo schreef ik onder meer: "Ik verwacht niet dat alle anoniemen hierop duiken en lezers voortdurend met cryptografische hashes in de weer zijn"), en ik probeer juist mogelijkheden te creëen om anoniem te blijven en desgewenst een van de nadelen daarvan te mitigeren.

Waarom dan dat gejank? Waarom niet alles lezen wat ik schreef maar mij wel afzeiken? Waarom laat Anomiem van 14:37 opzettelijk "[1]" weg bij het quoten van mijn tekst? Triest dit soort posts, duidelijk geschreven door trollen, en m.i. onterecht door de moderator(en) doorgelaten - iets dat steeds vaker lijkt te gebeuren op deze (m.i. -helaas- zinkende) site.

P.S. The thought crossed my mind.

Tijdje niet geweest. Ik bespeur steeds meer vaker topics op dit forum, van regelrecht aluhoedje gehalte tot "q" en "qanon" alt-right supporters. Brrrr..

Tijd om maar eens afstand te nemen van deze site en de "buitenlandse" gaslightende trollen die overigens perfect Neerlands spreken want het zijn net buren met hun lokaal dialect...

Mvgr,
Ron vd.


P.s. Het is een heel interessant idee van Erik van Straten. Ik zou zelf geen toepassing weten en blijf voor mijn beperkte internet activiteiten gewoon bij PGP voor wie het leuk vind om daar uit principe (omdat de mogelijkheid bestaat) gebruik van te maken zoals in 1995 toen PGP signing bijeenkomsten zeer populair waren. Uit principe en voor de fun natuurlijk.