ThomasChr Anwendung und Entwicklung ist strikt zu trennen;
Die Firma geht Pleite (a), das Produkt wird plötzlich kostenpflichtig (b) oder nicht mehr weiterentwickelt.(c)
(b) steht mal im Grundatzwiderspruch und stellt eben kein Problem dar;
(a) und (c) da gibt es - wenn es nicht gerade um wirkliche Nischen geht - Mitbewerber am Markt, auf welche man zurückgreifen kann;
Da kommt der Vorteil von opensource Software zum tragen. Die pflegt man einfach selber weiter.
wenn der Anwender zum Entwickler wird, ist vorher schon was schief gelaufen ...
das schlägt alles
"Apple Wants to Limit Certificates to Forty-Five Days"
wieso nicht gleich "Und täglich grüßt das Murmeltier" 
weil die sich zum Thema Privatschlüssel sorgen machen;
wer verwendet denn bei jeder Zertifikats'erneuerung' einen neuen Private-Key?
Anhand dem da, würde ich meinen da hat jemand eine auf der Klatsche
ASS was meinst Du, was Du jemals hattest und Dir heute denkst
"mann war ich damals für ein Dummie bei dem unsicheren Zeug"
und das unsicherste von allem haste heute immer noch 
Was nicht ok ist, ist der ZWANG bei JEDEM Login, egal zu welchem Zweck
die Zeiten ändern sich; vor PSD2 gabs smsTAN und jetzt halt was anderes ...
aRaphael die Mails sind DKIM signiert?, SPF ist ebenfalls korrekt?
Nein, beim CCP gibt es meiner Auffassung nach nur Sicherheitsaspekte und keine Finanzen.
das ist eine Frage der eigenen Präferenz etwas zu bezeichnen;
beim eBanking geht es ja dann auch nur um Sicherheitsaspekte;
es hat aber grundsätzlich etwas mit Finanzen zu tun;
und bei meinem eBanking brauchts beim 1ten cent eine TAN und das ist gut so;
zum finanziellen Schaden, den jemand anrichten kann; der kann bei manchen ein größerer sein,
wenn dessen Amazon-Konto, netcup-Konto, ... gehackt wird, gegenüber dem eigentlichen Bankkonto;
es war einmal, dass man die Zugangsdaten zum eBanking 'besser' schützt als z.B. zum netcup-Konto;
mittlerweile ist ein Konto mit Echtdaten grundsätzlich sensibel;
die Zugangsdaten zu einem WhatsApp-, Facebook-, ...-Konto mit Fake-Daten hingegen nur bedingt schützenswert;
welchen Sinn macht es, wenn eine Firma, einen neuen Webauftritt auf einem neuen Server - neue IP, aber alte bisher bekannte Domain - veranstaltet,
und dabei den alten Server, auf dem mittlerweile seit Monaten das SSL-Zert. abgelaufen ist, stehen läßt?
Vielleicht für den ein oder anderen ganz Interessant, die Zunkunft von .io sieht schlecht aus.
Sorgt der Klimawandel gerade dafür, dass Britisches Territorium im Indischen Ozean im Meer versinkt?
Win98SE4ever interessante Geschichte zu .su, wenn sie denn stimmt;
bei dem Domainpreis von einer .io-Domain seh ich schwarz, dass es hier ein Mittel gibt, der für den Fortbestand spricht
Du hast ja leider nicht genau beschrieben, was das Verhalten ist, das dich so wundert. Mir ist nur am Anfang der DNS-Lookup aufgefallen, man kann den aber mittels "ping -n6 http://www.orf.at" bleiben lassen, dann hängt da auch nix. Schuld am fehlenden Reverse-Lookup ist wohl 176.97.158.100.
genau das war der Hinweis ...
hatte nicht auf dem Radar, dass
ping hostname od. ping6 hostname od. ping -6 hostname
auf Unixoiden im Unterschied zu Windows ein Reverse DNS veranstaltet
und dieses liefert hier ein SERVFAIL 
wobei Frage: wie hast Du 176.97.158.100 bekommen?
generelle Frage: wie bekommt man die authoritativen DNS Server von subdomains, IP[v6] ranges,
wenn man dazu KEINE Info im whois findet?
will mal jemand folgendes Experiment machen:
Voraussetzung: funktionierendes IPv6
macht mal z.B.
ping6 www.google.com
od.
ping6 www.netcup.de
ganz normal wie man es eigentlich erwartet ...
so und nun das Experiment
macht
ping6 www.orf.at'
an Stelle von ping6 auch ping -6 möglich
sollte jemand hier ein Windows verwenden, dann gibt es hier echt keinen Unterschied,
aber wo zum Henker hackt es da bei Linux?
hat sich der ORF gegen Linux verschworen? 
hat jemand ein Linux mit IPv6 auf echtem Blech am Laufen?
hier ebenfalls das gleiche Verhalten?
ich merke es auf allen auf meinem System zu Hause laufen Unixoiden
egal welches Release, welche Distri, auf echt allen;
PC-BSD, Alma, CentOS, Fedora, ...
dachte am Anfang "des liegt sicher daran, dass des VMs sind"
denkste: bei Windows in der VM ist es nicht;
und auf meinem Windows Host auch nicht;
was ist das komisches?
was macht hier der ORF, sodaß dieses Verhalten nur bei Unixoiden auftritt?
hat es damit zu tun, dass hier einfach a paar Hosts mehr im DNS
unter www.orf.at sind?
# nslookup www.orf.at
Server: 46.38.225.230
Address: 46.38.225.230#53
Non-authoritative answer:
Name: www.orf.at
Address: 194.232.104.139
Name: www.orf.at
Address: 194.232.104.150
Name: www.orf.at
Address: 194.232.104.142
Name: www.orf.at
Address: 194.232.104.3
Name: www.orf.at
Address: 194.232.104.141
Name: www.orf.at
Address: 194.232.104.140
Name: www.orf.at
Address: 194.232.104.4
Name: www.orf.at
Address: 194.232.104.149
Name: www.orf.at
Address: 2a01:468:1000:9::140
Name: www.orf.at
Address: 2a01:468:1000:9::3
Name: www.orf.at
Address: 2a01:468:1000:9::149
Name: www.orf.at
Address: 2a01:468:1000:9::141
Name: www.orf.at
Address: 2a01:468:1000:9::142
Name: www.orf.at
Address: 2a01:468:1000:9::139
Name: www.orf.at
Address: 2a01:468:1000:9::150
Name: www.orf.at
Address: 2a01:468:1000:9::4würde ich jetzt nicht als die Menge betrachten ..., oder doch?
habe es soeben auch im Rescue mode eines meiner vServer gemacht,
wie auf all meinen Unixoiden Systemen, identes Verhalten ...
Moderatoren habt ihr einen Hinweis?
wer / was hackt da hinein?
ist es wirklich der ORF?
jetzt noch folgendes dazu:
ich betreibe meinen eigenen 6in4-Tunnel [jawohl mein ISP ist immer noch IPv4only gegenüber seinen Kunden]
und das Tunnelende hat in Relation zu mir eine Latenz von rund 9 ms
schaue ich mir auf diesem Tunnelende den Traffic mittels tcpdump an,
und filtere hier natürlich nur ICMPv6 Traffic, dann dauert des dort auch ewig bis das erste Packet überhaupt sehe?
sprich es vergeht hier schon eine Weile bis überhaupt der erste ICMPv6-Request raus geht, aber warum?
und das wie gesagt nur auf Unixoiden;
Der Logik folgend dürfte man dann auf einem Smartphone niemals gleichzeitig Passwortmanager und 2FA App installieren
das habe ich nicht gesagt; sondern dass der Passwortmanager nicht 2FA-App glztg. sein darf;
Auch ein Servicebetreiber kann Passwörter "verlieren".
wenn Du hier von Passwörtern im Klartext sprichst, ist gegen diesen Fauxpas ohnehin kein Kraut gewachsen;
und andernfalls, was will jemand mit irgendwelchem gehashtem Zeug?
Brute-Force, Viel Spaß
und jetzt kommt der Überhammer: da bringt 2FA genau nix, weil wer Passwörter ''verlieren" kann,
der kann auch 2FA-Secrets verlieren;
Denn sind wir mal ehrlich, wenn jemand deinen Passwort Manager angreifen kann, kann er auch deine 2FA App angreifen.
Ja und Nein. im Falle von TBT dass er seinen Passwort-Manager auch f. 2FA verwendet, macht man es dem Angreifer besonders einfach;
sprich ein Spickzettel mit dem Passwort neben dem Bildschirm und 2FA-App wird dann schon schwierig, da was brauchbares abzugreifen;
so mach ich es
DNS-over-HTTPS od. DNS-over-TLS nicht. SSL/TLS sind bereits etablierte Methoden, also werden sie hier halt auch eingesetzt, anstatt das Rad neu zu erfinden.
etabliert und zu Ende gedacht sind leider 2 Paar Schuhe;
der Quark ist einfach es über Port 443 mit SSL-Zertifikaten, welche IP(v6)-Adressen in den SANs haben zu handeln;
Wirklich getrennt wäre es nur, wenn Passwortmanager und 2FA nicht auf dem gleichen Smartphone ablaufen würde.
das ist nicht das Problem, sondern dass der Passwortmanager sich um die 2FA-Geschichte kümmert;
sprich der Zugang zum Passwortmanager darf nicht der selbe sein wie der zum 2FA;
weil das degradiert sonst zu 1FA;
In jedem Fall wäre jedoch die Verwendung eines Passwortmanagers dringend zu empfehlen.
Warum?
sobald man 2FA verwendet ist das Passwort nachrangig;
des kann durchaus einfach sein, und somit im Kopf
Valkyrie du sprichst von einem generellen Win11 Bug/Feature
Mit den heutigen Anforderungen an Passwörter sind Passwörter und TOTP die gleiche Faktor-Kategorie: "etwas, das man hat".
bevor die Geschichte mit 2FA kam, war das Passwort nichts anderes; und es deswegen heute mit dem TOTP zu EINEM Faktor zu verwschmelzen ist dennoch
weder empfohlen noch notwendig;
Die Aufbewahrung am selben Ort steigert das Risiko nur minimal, da immer beide gemeinsam benötigt werden.
das kann so nur zur Hälfte stimmen; weil etwas immer gemeinsam zu benötigen heißt ja nicht es auch gemeinsam aufzubewahren;
machst ja bei der Geldkarte auch nicht, dass Du den PIN gleich auf die Karte schreibst
Hängt davon ab, um welches Szenario es geht.
eigentlich nicht; 2FA ist nur dann 2FA wenn es auch wie 2FA gehandhabt wird;
Dein vorgehen ist wie das Aufbwahren der Geldkarte gemeinsam mit dessen PIN;
so wie dann jemand das "Masterpasswort" braucht, braucht jemand dann auch nur die Geldkarte - beides ist nur EINE Hürde;
dass man den PIN nicht mit der Geldkarte aufbewahrt ist jedem einleuchtend;
aber dass man auch den 2ten Faktor - die H/TOTP-Geschichte - getrennt von den Zugangsdaten aufbewahrt wär auf einmal was völlig absurdes? 
wobei bei der ganzen Geschichte die einzelnen Implementierungen¹ Aufholbedarf haben;
¹ hier nicht die Passwortsafes, ... gemeint, sondern die tatsächlichen Sites wo man diese Anmeldedaten verwendet;
Verstehe immer noch nicht, warum das Quark sein soll. Aber egal, muss du ja nicht nutzen
was heisst HTTP?
Hypertext Transport Protocol
HTTPS ist die Erweiterung es in SSL/TLS-Kanälen zu übertragen
Was zum Geier hat da DNS verloren?
od. Was zum Geier haben Radfahrer am Pannenstreifen auf Autobahnen verloren?
wie gesagt, es wurde nicht zu Ende gedacht
Hast du den Sinn von DOH bzw DOT überhaupt verstanden bzw dich mal damit beschäftigt? Der Sinn dahinter ist nämlich ein ganz anderer
ich hab den Sinn schon verstanden, die Umsetzung ist halt Quark
wie gesagt, es wurde nicht zu Ende gedacht;
den Pannenstreifen auf Autobahnen gibt ja auch niemand für den Fahrradverkehr frei, oder?
