Ich mach Pause von Kodi

Okay Leute ich hatte gerade mal in der Mittagspause ein paar Minuten um zu experimentieren.

Was habe ich gemacht?
Ich habe mir so ne alte MeCool Box geschnappt die hier noch rumfliegt und CoreElec mit Kodi 20 aufgespielt.

Dann TVH 4.3 drauf, den Einrichtungsassistenten habe ich eher Stiefmütterlich behandelt, den kann man ja wegklicken dann wird ein User angelegt mit vollen rechten, ohne PW der von überall aus auf die WebGUI zugreifen kann.

Das an sich ist natürlich schon irgendwie doof wenn ich das nun ins Netz hänge.

Jetzt kommt aber der Clou. Über das Preprocessor Command der TVH Recording funktion kann ich beliebige Befehle im Kontext des TVH User ausführen und der ist bei CoreElec natürlich: root!

Also kleinen Einzeiler da rein um eine Reverse Shell auf meinem kleinen Test VPS aufzumachen, eine Aufnahme starten und ich habe root Zugriff auf die CoreElec Kiste.
Dafür muss auf dieser weder ssh aktiviert sein, noch muss ich irgendein Portforwarding (ausser das zur WebGUI von TVH) eingerichtet haben.

Als root kann ich auf der kleinen Kiste alles machen, zum Beispiel die eingebunden Samba shares löschen, verschlüsseln etc.
Ich habe einen Brückenkopf ins Netzwerk.
Sicher kann ich mich dann auch auf der Kiste verankern, ich lass die reverse shell einfach per autostart nach jedem Reboot etc wieder öffnen.

Ich meine hier kommen natürlich ein paar Dinge zusammen. Das Fehlen eines Passworts beim TVH User ist natürlich der Knackpunkt aber TVH zwingt einen auch nicht ein PW zu vergeben, was eigentlich "best practice" wäre.

Zitat von DaVu

Dann lass es. Sind ja deine Systeme. Das ist ein gutes Beispiel einer Empfehlung, die ich nicht weiter empfehlen kann

Einfach gute Gegenargument zu dem was ich gesagt habe waeren hilfreicher!

Zitat von DaVu

Das ist ein Widerspruch in sich. Wenn ich leicht an ein Passwort komme, weil ich es "entschlüsselt" habe, dann brauche ich kein Brute Force mehr. Denn dann kenne ich das Passwort ja schon . Eine Brute-Force Attacke stellt einen Angriff dar, wo ich Passworte so lange ausprobiere bis eines passt. Für einen Brute-Force Angriff muss ich das Passwort nicht entschlüsseln.

Brute Force heisst einfach, alle moeglichen Passwoerter auszuprobieren. Und das geht halt sehr schnell nur, wenn man Zugriff auf das verschluesselte Passwort hat. Das war frueher bei Unix einfach, weil das halt verschluesselt im /etc/passwd stand und fuer jeden lesbar war. Um diesen Angriff auszuschalten wurde /etc/shadow eingefuehrt, was nicht lesbar fuer welt ist sondern nur fuer root. Also muss man erst mal root sein um an die verschluesselten Passwoerter zu kommen, um die dann zu knacken. Frage: Warum will man passwoerter knacken, wenn man schon root ist ? Klar, gibt Antworten, aber letztendlich ist es ja genauso wichtig zu verhindern, das jemand auf anderem Wege root wird.

Und die ganze Cryptosecurity Empfehlungen fuer laengere, komplexere Passworter schauen halt nur auf den Fall, das die verschluesselten Passwoerter vorliegen und brute force geknackt werden koennen. Also muss man vorher ansetzen. Was ja auch alle Software macht - falsches passwort: 10 sekunden warten bis naechses Passwort ausprobiert werden kann. Ueber die Programme wo man sich authentifizieren kann geht also nur eine begrenzte Menge passworter auszuprobieren. Und diese Menge aendert sich auch nicht durch Quantum Cryptographie.

Zitat von DaVu

Versteh mich nicht falsch. Sagst du jetzt nur was um "was gesagt zu haben". Wenn ich den Satz 2 Mal lese, dann steht da: "Wenn jemand root hat, dann hat er das System ja eh schon gehackt weil er root ist". Sherlock Wenn ich root habe, dann habe ich root. Dann gehört das System mir. Punkt aus Basta unabhängig davon welche Datei ist als root lesen kann oder nicht. Wenn ich Dateien lesen kann, die root-Rechte erfordern, dann habe ich wohl die richtigen Rechte

Vielleicht war dir das mit der "Vor /etc/shadow", "Nach /etc/shadow" Zeit nicht klar. Ich war davon ausgegangen das das klar ist, wollte aber mit meinem Satz die Konsequenzen verdeutlichen. Systemsicherheit ist zu verstehen wann oder ob ein laengeres/komplexeres password hilft. Und es hilft halt nicht, wenn man nie an das verschluesselte Passwort kommt und nie das unverschluesselte Passwort schnell ausprobieren kann.

Man darf halt nur keine so einfachen/ueblichen Passwoerter verwenden, das die wirklich auch ueber die normalen Schnittstellen in endlicher Zeit ausprobiert werden koennen. Aka: Einfach ausrechnen, wieviele passwoerter getestet werden koennen, wenn nur eins alle 5 sekunden ausprobiert werden kann.

Zitat von DaVu

Du ...sei mir mal nicht böse, so langsam wirds peinlich. Ja, ich gebe dir Recht....man speichert keine Passworte bei Cloud-Dienstleistern. Aber nur, weil ich von außen ran kommen möchte, muss das Passwort nicht leicht sein.

Die Erfahrungen mit Menschen belegen halt, das die meisten Passwoerter die "geknackt" werden halt nicht durch automatisierte Softwareangriffe geknackt werden, sondern weil die irgendwo unverschluesselt aufgeschrieben waren. Deswegen muss man sich passwoerter halt vor allem so gut merken koennen, das man sie nicht aufschreiben muss. Das ist am einfachsten halt ein langer begriff/satz.

Zitat von DaVu

Es gibt für jedes Endgerät lokale Passwortmanager (Keepass z. B.), die komplexe Passworte verschlüsselt in einer Passwort-geschützten Datenbank speichern können, die ich "portabel" machen kann. Ich kann sie also von meinem PC auf mein Telefon oder auch ein anderes Endgerät kopieren. Wenn du jetzt sagst, dass ein Passwort leicht sein muss, damit ich es mir merken kann, dann bist du einfach auf dem Holzweg.

Und Du hast gerade einen neuen Angriffsvektor erzeugt, naemlich den Passwortmanager, ueber den jetzt auch noch gleich die Passwoerter mehrerer Rechner gehackt werden koennen, und man braucht dafuer nur noch ein passwort.

Zitat von DaVu

Ich kann sogar noch einen Schritt weiter gehen und könnte meine Keepass-Datenbank verschlüsselt via git-crypt auf GitHub ablegen und das entschlüsseln nur mit GPG-Key ermöglichen. Dann kann sich jeder diese Datei runter laden. Selbst wenn er dann GPG geknackt hätte, dann wäre die Datenbank immer noch verschlüsselt und mit einem komplexen Passwort versehen. Dieses Passwort zum entschlüsseln der Keepass-Datenbank ist das einzig komplexe Passwort, welches ich mir merken muss. und da geht dann auch sowas folbujoRRas!hackermuessendraußenbleiben!. Da ist der komplexe und "sinnfreie" Teil bis zum ersten ! und da sind es auch 12 Zeichen Alle anderen Passworte, die ich für den Zugriff "von außen" auf mein Netzwerk benötige, die auch jeder andere versuchen kann, müssen halt verdammt nochmal sehr komplex sein.

Natuerlich kann man auch mit Kanonen auf Spatzen schiessen, aber man sollte das Problem halt soweit verstehen, das man weiss ob man das macht, oder ob man da einen wirklich realen Angriffsvektor verhindert. Wie oben gesagt: Wenn Du ein passwort eben nicht mit Quantumcomputer angreifen kannst, sondern nur mit einem passwort alle 5 sekunden - wie komplex oder lang muss es dann sein ? Wenn Deine Antwort ist, das es prinzipiell genau so lang sein muss wie wenn Du es mit quantum Computer angreifen kannst, dann schiesst Du halt gerne mit Kanonen auf Spatzen. Und ich spreche niemandem sein Hobby ab.

Denk einfach mal an die Geschichte wie die beim FBI dagegen angekaempft hatten, das Apple System so geschuetzt waren, das die die 5-stellige PIN nicht durch brute force knacken konnten. Also wurde da viel Geld fuer Leute bezahlt die das System (iPhone) geknackt haben. Da haette dann auch eine komplexere PIN nicht geholfen.

Zitat von DaVu

Mit sowas wäre ich vorsichtig. Wie du schon selbst sagst, gibt es eine entsprechende Passwort-Datei, diese Datei hat, soweit ich weiß, mittlerweile eine Größe von 40GB. Da steht mir Sicherheit auch sowas drin.

Naja, wenn die Jungs gut sind, dann steht das demnaechst nach diesem Fred drin, weil die vielleicht Word scraping auf dem Internet machen. Aber sich mal genau so eine Datenbank runterladen und da reinzugucken, das hilft dem Verstaendnis. Vor allem, wenn man das Jahrzehnte lang macht. So billige Passwoerter die ich nur fuer irgendwelche Internet Forenwebseiten verwende tauchten mal nach 20 Jahren in so einer Liste auf. Aber halt eben auch ohne Zuordnung zu den foren Usernamen. Da war also mal so eine unverschluesselte Passwortdatei von so einem Forum geleaked und von Hackern in die ewige Liste reingetan.

Zitat von DaVu

Seither hat sich ein wenig was verändert. Vielleicht solltest du dich erstmal wieder auf einen aktuellen Stand bringen, bevor du hier implizit Empfehlungen aussprichst. Du stellst in dem Fall ein Risiko dar. Sorry, wenn ich das mal so hart sagen muss. Aber du sagst, dass komplexe Passworte keinen Sinn ergeben. Das ist leider seit langem der größte Unsinn, den ich gelesen habe.
Nicht böse sein.

Wie gesagt: Bring echte Gegenargumente, statt einfach nur, wie in dieser Antwort von Dir drei mal en-passant veraechliche, abwerte Bemerkunden zu machen ohne meine Argumente wirklich zu widerlegen.

Bei dem Bezug auf 1988 ging es ja vor allem auch darum, das seitdem hoffentlich viel mehr von den Hacking Angriffsvetoren geschlossen worden sind - was aber leider haeufig nicht stimmt. Er eine Artikel von 2017 den ich zitiert habe hat ja man schon buffer Overflow Angriff als etwas bezeichnet das es noch mindestens ein Jahrzeht gab, und der Wikipedia Artikel macht mich wundern, ob, wieviel solche Buffer Overflow Angriffe immer noch bei Systemen, wie ARM z.b. gehen.

Mich nervt halt vor allem dieser Tunnelblick auf Quantum Cryptographie und die Annahme das man sich dagegen schuetzen muss bei seiner Passwortkomplexitaet. Dabei ist halt die Wahrscheinlichkeit eines Quatum Cryptographie Angriffes vor allem bei oeffentlich verschluesselten Daten gegeben, also z.b. Deiner github Idee. Und Dingen die mit public keys verschluesselt sind. Da muss man ja "bloss" den public key knacken. Und wieviel da die State Level actors knacken koennen weiss wirklich keiner. Was nur systematisch zu verfolgen ist, ist das die seit Jahrzehnten halt immer versucht haben, die cryptoverfahren waehrend der Standardisierung so zu veraendern, das die einfacher zu knacken sind.

Aber bei Systemen, wo die passwoerter halt nirgends, auch nicht verschluesselt oeffentlich verfuegbar sind, da gibt es halt diesen Angriffsvektor nicht. Da geht es darum, das das System keine Hacks erlaubt, mit denen man ohne passwort root wird und das das ausprobieren von falschen Passwoertern nur langsam geht und geloggt wird. Und dann kommt man eben auch sehr einfach mit einem leicht zu erinnernden Passwort aus. Sowas was ich vorgeschlagen hatte. Avber natuerlich nicht mehr genau dieses - weil das ist ja verbrannt dadurch das es hier im Forum stand.

@DaVu

Wenn man Zugriff auf ein verschluesseltes Passwort hat, dann kann man viel schneller durchprobieren, was das passwort ist, als wenn man das Passwort nur ueber die "normale" Benutzerschnittstelle ausprobieren kann. Also beim ssh login, oder web authentifizierung. Da wird ja ein throttling eingebaut, so das man da eigentlich nicht mehr als ein passwort alle paar Sekunden ausprobieren kann.

Beim Zugriff auf ein verschluesseltes Passwort kann man dagegen Millionen, Milliarden oder noch mehr Passwoertern pro Sekunde ausprobieren. Und diese Geschwindigkeit erhoeht sich wegen Quantencomputern fuer nocht-quantenfeste Verschluesselungsalgorithmen in eine Masse was vor Quantencomputern nicht absehbar war.

Die ganzen Empfehlungen fuer die "notwendige" Laenge/Komplexitaet von Passwoertern beziehen sich auf die Annahme, das man Passwoerter sehr schnell ausprobieren kann. Wenn sie davon ausgehen wuerden, das da nur ein passwort alle 10 Sekunden ausprobiert werden kann, dann reicht natuerlich ein viel einfacheres Passwort.

"Brute Force" heisst erst mal, das beim ausprobieren einfache alle Passwoerter ohne Intelligenz ausprobiert werden.

Listen von bekannten Passwoertern sind Beschleunigungen. Nach meinem Verstaendnis sagt man nicht mehr Brute Force wenn Passwortlisten verwendet werden. Aber das ist natuerlich nur Linguistik. Passwortlisten sind atuerlich gerade dann notwendig (fuer den Hacker), wenn er nur langsam ausprobieren kann. Wenn man weiss das das Passwort zwar auch verschluesselt nicht oeffentlich wird, dann muss es zwar nicht so lang/kompliziert sein, es darf aber eben auch nicht offensichtlich sein, das es in einer passwortliste auftauchen koennte, oder sonstwie von intelligenteren Probierern produziert werden koennte.

Das /etc/shadow wurde vielleicht zum ersten Mal 1987 eingefuehrt, aber das letzte System ohne /etc/shadow wurde sicher nicht frueher als 10 Jahre spaeter abgeschaltet oder upgegraded...

Bei der Passwortwahl ist halt vor allem wichtig, das der Benutzer sich das merken kann und nicht aufschreiben muss oder sonstige Tools braucht, die ein zusaetzlicher Angriffsvektor sind. Da gehen natuerlich die Meinungen auseinander, aber mir gruselt es davor, alle Passwoerter auf eine Karte zu setzen (ein gemeinsames Tool, ein Passwort von dem alle anderen abhaengen)

Die Komplexitaet zum knacken von Passwoertern ist natuerlich hoeher wenn gross/klein/sonderzeichen usw. verwendet werden, als wenn man nur kleinbuchstaben verwendet. Aber man kann ja leicht beide Methoden in entropie umrechnen (echte zahl an informationsbits). Da ist dann ein Satz aus nur kleinbuchstaben vielleicht maximal doppelt so lang wie einer mit gross/klein/sonderzeichen. Aber halt einfacher zu merken (fuer viele Menschen).

Bei Deiner oeffentlich verschluesselt vorliegenden Datei ist das wahrscheinlich am Ende so, das da ein Hacker maximal schnell die Passwoerter durchprobieren kann. Da sollte man schon gucken, was die passenden Laengenempfehlungen gegen brute-force attacken heute sind. Und dann halt ueberlegen, ob man die notwendige zahl informationsbits lieber mit Sonderzeichen oder lieber mit mehr kleinbuchstaben macht um es zu erinnern.

Aber ein Passwort fuer ein login auf einem TVH oder sonstigen System kann halt, siehe oben, viel einfacher sein und trotzdem genau so sicher, weil es halt nicht denselben (schnellen) angriffen ausgesetzt sein kann. selbst wenn da kein grosses sleep zwischen versuchen ist, ist die geschwindigkeit ja durch die Leistung deines Rechners auf wenige hundert Versuche oder so pro Sekunde limitiert.

Die Moeglichkeit von Menschen, sich Passwoerter zu merken unterscheiden sich gewaltig. Deswegen ist es auf jeden Fall sinnvoll ziemlich gut zu wissen, wieviel entropie wirklich hinreichend in jedem Anwendungsfall ist. Und wie die dann am einfachsen zu merken als Passwort umgesetzt werden sollte fuer den Benutzer. Ich bezeichne halt das, was da jenseits des hinreichenden an Entropie eingebracht wird als Hobby.

Ich finde halt fuer die Anwendung Passwort fuer "Webserver zuhause" die von Dir empfohlene Passwortkomplexitaet fuer deutlich jenseits des hinreichenden. Und wollte das nur mal erwaehnt haben, weil es IMHO eine nervige Vereinfachung ist, wenn bei Passwortempfehlungen nicht zwischen den Angriffsszenarien unterschieden wird. So wie Du das geschrieben hast muesste man ja statt einer PIN beim Handy auch ein langes komplexes Passwort mit Sonderzeichen eingeben. Und das ist ja halt nicht notwendig. Aber wenn mans machen will: Klar. Ist dann halt Hobby.

Zitat von DaVu

Warum soll ich da unterscheiden? Ich mache doch ein Passwort nicht weniger sicher nur well der Angriffsvektor ein geringerer ist

Du hast also Dein Handy so konfiguriert, das Du statt PIN oder Fingerabdruck jedes mal ein 15 zeichen Passwort mit Sonderzeichen eingeben musst ?

Zitat von DaVu

Du wiegelst hier Bequemlichkeit gegen Sicherheit auf.

Nein, ich erklaere, das man die Angriffsvektoren verstehen muss damit man hinreichenden Schutz bauen kann. Und die Angrifffsvektoren sind halt nicht ueberall gleich.

Zitat von DaVu

Bei einem Basic-Auth wie bei TVH gibt es kein Throttling, da es nur "Basic Auth" ist.

Basic-Auth definiert ja nicht ob oder ob Du nicht nach einem Failure eine Verzoegerung machst.

Zitat von DaVu

Ein Selenium richtig konfiguriert und ich lasse das halt mal so lange laufen, bis derjenige mal in seine Logs schaut. Und ich kann da im Sekundentakt Passwort drauf feuern, wenn ich will.

Klar. Und wenn Du es parallel machst und dein Server multi-threaded konfiguriert ist (keine AHnung was bei TVH geht), dann vielleicht Faktor 10 oder so pro sekunde. Die maximale Angriffsrate sollte man verstehen und dann ist es natuerlich viel einfacher zuerst einmal diese Rate mit allen Hilfmitteln soweit wie moeglichst zu reduzieren - statt sich schwierigere Passwoerter merken zu muessen.

Selbst 10 Versuche pro Sekunde von einem Selenium sind ein Bruchteil dessen, was ein Angreifer erreichen kann, wenn er in der Cloud oder auf einem Quantencomputer das "verschluesselte" passwort versucht zu cracken.

Zitat von DaVu

Bei anderen Anwendungen sieht das natürlich anders aus. In Foren kommt dann irgendwann ein Captcha etc. pp..Andere Dienste nutzen halt Fail2ban oder ähnliche mechanismen.

Naja, in wie weit solche Dienste das machen, im sich gegen passwort cracking zu schuetzen weiss ich nicht. Ich dachte immer, das ist dagegen das Robots sich accounts einrichten oder so. Aber klar. Sind alles gute Hilfsmittel um die Angriffsrate an Passwortcracken zu reduzieren.

Zitat von DaVu

Aber nur weil ich weiß, dass dieses Forum hier ein Captcha schaltet, wenn ich 3 Mal mein Passwort nicht richtig eingebe, so ist mein Passwort hier doch nicht weniger komplex. Das eine hat doch mit dem anderen nichts zu tun.

Doch hat es. Genau solche Massnamen sind der Grund, warum es Milliarden von Handys geben kann, die nur mit INs gesichert sind, und das nicht schon hunderte Millionen mal schief gegangen ist (pi * daumen ist 100 Millionen die geratene Zahl geklauter Handys

Zitat von DaVu

Wie gut, dass du nicht verantwortlich für meine Server bist.

Das beruht ja auf Gegenseitigkeit. Ich habe schon viel zu viele Server, wo mir die Systemadmins viel zu komplizierte Passwoerter aufdrucken wollen. Voll die Volkskrankheit. Gerade ein neues Server Motherboard gekauft, und bei dem neuesten Modell konnte ich beim IPMI nicht mehr die viel zu komplizierten Passwortregeln abschalten. Und natuerlich wird das IPMI nie zum Internet freigegeben. Also wurde es dann eine Motherboard das eine Generation aelter war.

Zitat von DaVu

Ein verschlüsseltes Passwort zurück zu rechnen ist ähnlich aufwendig bis unmöglich wie bei einem komplexen Passwort mit Brute Force. Das was du meinst ist die Rainbow Table Attacke. Eine Attacke wo ich den Hash eines verschlüsselten Passworts habe und diesen Hash mit anderen Hashes gängiger Passwort vergleiche. Wenn ich natürlch nur base64 zur Kodierung verwende (NEIN....base64 ist KEINE Verschlüsselung), dann kannst du diees bestimmt recht einfach zurück rechnen: YWRtaW4K. Das ist ja auch nur Codiert.
Wenn du es schaffst dieses Passwort zurück zu rechnen, dann komme ich zu dir und trinke nen Bier mit dir. Versprochen:

$5$2GvlV46yxeOoiMfm$XInS/FRmIZDw4lVUNPusuKJshixf3LeJFcsEyoa8BdB

Nee, danke ;- Aber ja, wenn ich "verschluesseln" gesagt habe war das bissl kindertalk. Natuerlich sind das meisten hashes. Wenn man da high-performance cracking macht, dann rechnet man halt genau dasselbe, was auch der originale Server rechnen wuerde. Bloss das man das jemanden machen laesst der das mal schnell auf 5,000 NVidia GPUs mit code macht der fuer diese Hashfunktion optimiert ist.Oder HW (so wie bei BitCoin). Ich glaube die QuantumDekodierung ist eher auf sowas wie RSA (also public keys) ausgelegt.

Aka: Geht halt um Faktoren von mindestens 100,000 oder so gegenueber dem was Du durch ausprobieren am echten Server/GUI erreichen kannst.

Zitat von DaVu

Also...jetzt nehmen wir an, ich habe oben genanntes Passwort in meinem Server eingesetzt und du hast jetzt diesen Hash....wie schnell kannst du es zurück rechnen?

Das bekannteste sind ja wohl SHA1 gehaste passwoerter. Kannste ja mal googlen. Google hat da ja 2017 SHA1 sehr schnell gecrackt. Deswegen wird das seitdem ja auch aus CryptoSuites verbannt. TLS, Java, etc. pp. Und es sind ja wohl passwortdateien mit sha1 gehashten passwoertern geleaked von sowas wie facebook.

Zitat von DaVu

Sondern?

Keine Ahnung obs da Fachbegriffe fuer gibt. Aber wie Du schon erwaehnt hattest gibt es ja das zusaetzliche Problem, das man passwoerter eben auch so hashen muss, das man da nicht einfach eine gehaste Passwortliste erbeuten kann, und dann mit wahnsinniger Geschwindigkeit gegen gehashte passwortlisten vergleichen kann. Sondern zumindestens den Aufwand hat, mit maximaler performance die hashfunktionen zu imlementieren. Und dann gibt es ja noch die NSA die eine traurige Historie hat, alle arten von Cryptofunktionen in der Standardisierung aufzuweichen, damit sie die selbst einfacher knacken kann.

Aka: man will wirklich am liebsten Sicherheit dadurch kriegen, das die Passwoerter um die es geht nie, auch nicht gehasht, von Viren, oder sonstwie erbeutet werden. Und das man die offizielle Abfrageschnittstelle throttled. Das beides ist wirklich die "first-line-of-defense". Passwortlaenge kommt lange dahinter. Halt bei den Anwendungen wo das so geht. Wie webserver. Also vor allem keine "possibly gruntled employees" einstellen, die leaken koennen (zuhause: Geschwister etc.. ;-).

Zitat von DaVu

Du hast dir den Link oben noch nicht mal angesehen, oder? 15 Zeichen....Groß- Kleinbuchstaben und Zahlen ohne Sonderzeichen == 11.000.000.000 Jahre!!!!! 15 Zeichen sollte sich jeder merken können bzw ein Fantasiewort erfinden und dort noch eine Zahl und ein Sonderzeichen einbauen können. Das ist keine Raketenwissenschaft. "fromBulolombus12" "MakunTada13$" Soll ich weiter machen...das hat keine 10 Sekunden gedauert und man kann sich beides merken.

Also ich koennte mir das halt nicht mehr merken. Und solange Du da keine bewiesene maximale Rate hast, mit der crack/rate-versuche gemacht werden koennen, wuerde ich mich angesichts der Quantencomputer nicht darauf verlassen, das selbst eine Milliardenzahl wirklichlange braucht wenn es jemand mit genuegend resourcen darauf anlegt, das zu cracken. Das ist doch im Moment so, das alle komplexen Algorithmen, insbesondere public key die es gibt als nicht-quantum-compute safe eingeordnet werden (bei hashes weiss ich nicht genau). Die NIST Kampagne, um quantum-safe algorithem zu definieren laeuft noch. Und in der zwischenzeit setzen die, die maximale Sicherheit wollen auf maximal lange symmetrische schluessel die dann ueber vertrauliche wege transportiert werden muessen.

Zitat von DaVu

Liest du meine Beiträge? TVH hat nur Basic-Auth. Da feuer ich Passwort drauf bis ich doof werde. Da blockt mich gar nichts. Ich muss einfach nur die Seite aktualisieren. Man KANN!!! Fail2ban einrichten. Das ist aber mit ein wenig Aufwand und Wissen verbunden und DAS hat nicht jeder. Ist es da nicht wesentlich einfacher ein komplexes Passwort zu verwenden.....für dich anscheinend nicht

Es ist halt komplett unverantwortliche Verantwortung abwaelzen, wenn Webservises so implementiert sind, das sie nur die Nutzer mit maximal komplexen Passworanforderungen qualen aber selbst nicht mal die simpleste Ratenkontrolle implementieren.

Aber klar. Eigentlich sollte man auch auf der Fritze so eine Ratenkontrolle fuer Verbindungsversuche und besseres connection [definition=12,8][definition=12,9]logging[/definition][/definition] haben. Ach was, braucht man alles nicht. Einfach Milliarden von Menschen moeglichst viel komplexe Passwoerter lernen lassen. *grmbl*.

Zitat von DaVu

Naja...egal. Wir werden uns da wohl nicht einig. Mach was du willst und ich mache was ich will

Mach mal ein Video wie Du dich mit Sonderzeichenpasswort auf dem Handy einloggst ;-))

Zitat von DaVu

Aber bitte werde nicht implizit zum Risiko für unwissende.

Solange man das Problem nicht besser versteht kann man ja eh nur hoffen, das die Lehrmeinung stimmt, und das ist ja die, die Du vertrittst: Laenger und komplexer ist besser. Du versuchst ja auch schon zwischen verschiedenen Typen von Passwoertern zu unterscheiden. Das einzige was ich da mehr gesagt habe ist:

- Eigene Webservices erst mal so aufsetzen, das die Angriffsrate minimiert wird (wenn geht). Und die maximale Angriffsrate verstehen.
- Notwendige Passwortkomplexitet ist abhaengig von Angriffsrate. Aber halt nie passwoerter verwenden, die in passwortlisten stehen koennten
- Wenn man sich komplexe passwoerter nicht merken kann, dann einfach passend noch laengere einfachere texte nehmen, die man sich merken kann. Statt die woerter direkt aneinander zu haengen oder leerzeichen auch gerne jweils mit sonderzeichen separieren. Muss dann sagen wir mal 30% laenger seein als mit gross/klein/ziffern.

@te36 @DaVu Bis einer weint.
Ich meine zwar auch das man ein ausreichend sicheres Passwort pro Dienst braucht aber das ist halt kein Thema.
Hier ist das Problem um aufs OnTopic zurück zu kommen das der Standarduser mit ohne Passwort offen im Internet per Portweiterleitung rumläuft. Da TvH teilweise mit rootrechten läuft führte das dann zum nächsten.
Also das Problem liegt hier eindeutig in der falschen Einrichtung. Da bin ich auch der Meinung das TvH einen dazu zwingen muss ein Passwort zu setzen.
Eingebautes Fail2Ban wäre dann auch noch die Kür.

Zitat von SkyBird1980

@te36 @DaVu Bis einer weint.

Also wir halten das beliebig lange durch, aber wir wollen natuerlich nicht das Du weinen musst

Stimme Dir in allem zu. Werde auch mal Fail2Ban installieren.

@darkside40 Danke fuer die validierung. Das ist ja schon ein starkes Stueck. Software die einen webservice anbietet ohne ein nicht-default-passwort zu forcieren. Ok. Kacke. Aber eine Software, die dann auch noch rootshell zugriff dadurch leicht ermoeglicht. Krass.

Scheint ja leider in keinem repo drin zu sein die auch cve haben (debian, ubuntu), sonst koennte man die da sofort rauskicken lassen wegen sowas.

Unter Debian, Ubuntu und Co. liegt der Fall anders.
Hier erzwingt TVH bei der Installation auf der Shell das anlegen eines benutzer Account.
Des Weiteren läuft TVH unter diesen Systemen standardmäßig nicht als root sondern als eingeschränkter Nutzer hts.

Bei LE/CE kommt hier schon einiges zusammen damit der Angriff so klappt.

Aber wir können das auch weiter spinnen. Kodi läuft auf diesen OS sicher auch als root. Was hält mich davon ab ein super tolles "Stream-dir-die-neuesten-Filme"-Addon zu schreiben und darin eine reverse Shell aufzumachen, die mir dann auf der kleinen Kiste wieder root Rechte gibt.

Wenn man den Leute das so klar macht das Sie so auf einmal jemand fremdes in Ihrem Netz haben wird die Argumentation gegen illegale Addons auf einmal viel einleuchtender.

Angriff mit Passwort Listen ist doch eine Version eines lexikalen Angriffs oder?

Bruteforce profitiert von einer verringerten Komplexität letztlich erst dann, wenn es die Verringerung vermutet. Gehe ich einfach ohne Vorwissen rein, teste ich alle Kombinationen aller Zeichen. Nun rate ich das nur Kleinbuchstaben verwendet werden. Also gehe ich erst alle Kleinbuchstabenkombis durch und dann erst erweitere ich das Spektrum. Selbiges bei Passwort Länge. Logisch wäre ein Austesten nach typischen Längen : zuerst vorgegebene Mindestlänge, dann empfohlene Mindestlänge, dann das jeweils +1 usw. Das führt dazu das bei typischen Bruteforce Angriffen teils auch wenig komplexe Passwörter sehr sicher sind.
Dummes Beispiel: #########+++++++
Das Passwort ist nicht komplex, aber zumindest lang. Ein typischer Bruteforce braucht hier eher lange. Setzt der Bf aber andere Prioritäten kann es sein, daß er es schnell löst. Nur es muss halt vermutet werden das nur Sonderzeichen verwendet werden.
Letztlich ist das der Grund warum man von allem etwas nutzen sollte, da selbst richtiges raten einem hier beim Ausschluß nur wenig hilft.
Warum waren die Wlan Schlüssel von Fritzbox schon immer Müll (mal abgesehen von der Zeit wo man sie aus bestimmten Daten errechnen konnte)? Bekannte Länge + eingeschränkte Zeichenauswahl (nur Zahlen). Hier hilft dann die Länge zwar immernoch aber sehr viel weniger als bei anderen Passwortes.
Was kann mann noch raten z. B. verwenden von Worten. Großbuchstaben an Wort Beginn. Position von Sonderzeichen usw.

Letztlich wird für Bf aber immer DEUTLICH einfacher sein lokal arbeiten zu können. Das verringert die Zeit pro Versuch sehr sehr stark. Es ermöglicht mir oft auch parallel mehrere Systeme zu nutzen. Gehe ich hin und muss immer wieder eine Seite reloaden kostet das ne Menge Zeit und es bietet jede Menge Möglichkeiten den Angriff zu bemerken. Da ist mir ne Keepass Datei allemal lieber als nen Webinterface (nur auf Bf bezogen).

Warum sollte ich das machen?
Weder will ich nen Bf auf nen Interface machen noch auf eine Datei. Beschäftigt habe ich mich mit dem Thema, aber das bedeutet doch nicht, daß ich a) die passende Hardware habe b) die Kosten zahlen will noch c) mir den Aufwand geben will nur um einen Punkt scheinbar zu beweisen.
Aus einem einzelnen Experiment ergibt sich kein Beweis. Wenn man überhaupt was machen würde, dann würde man kucken wie weit man es optimieren kann ein Passwort zu testen vs Webinterface bzw. lokale Datei. Dann zu kucken in welchem Maße das skalierbar ist.
Und das kann man recht leicht voraussagen das ein Versuch vs lokaler Datei wesentlich schneller und skalierbare ist. Das lohnt den Aufwand nicht.

All das heißt natürlich nicht das ne Keepass Datei etwas ist was man bei vernünftigen Passwort eben knackt. Aber man hat da unlimitierte Zeit und die Möglichkeit unlimitierte Ressourcen drauf zu werfen. Klar irgendwann sind alle Passwörter darin veraltet, aber selbst aus den veralteten Passwörtern kann ich Schlüsse ziehen und ich hab ja dann auch auch schonmal Nutzernamen und Seiten auf denen man angemeldet ist/war.

Auf der Shield läuft sicher kein LibreElec etc drauf.
Android hat ein anderes Sicherheitskonzept solange du keine illegalen Addons nutzt biste da safe.

Naja, viele denken das ein Geburtstag oder der Name des Haustier die Daten sind die ein Passwort schwach machen. Aber Schwächen tun alle Regeln die ich verwende die mein Gegenüber ggfs ermitteln/raten könnte.
Z. B ich mach immer 20 Zeichen. Ich verwende keine Worte usw. All das nimmt Kombinationen raus. Oder das typische Sonderzeichen am Anfang/Mitte/Ende. Gut diese 3 Beispiele nehmen nur eine begrenzte Zahl von Kombinationen raus, so dass das 20 stellige Passwort immernoch ewig dauern würde, aber die Fortschritte in dem Bereich sind groß und einmal weggeben, hat jemand auch nach Jahren noch die Möglichkeit das zu knacken. Zumal es auch immer wieder Schwächen in der Implementation von Verschlüsselung gab bzw Schwächen ihrer Grundstruktur erst später ersichtlich wurden, die ein Knacken ohne Bf ermöglichten bzw. eins mit erleichterten. Gib eine solche Datei nur mit Beispiel aber niemals mit Realdaten aus der Hand.

Aber es ging primär um lokal vs Webinterface.
Beim Webinterface hab ich die Chance es zu bemerken. Beim Webinterface sind die Laufzeiten deutlich höher. Beim Webinterface kann ich nur sehr limitiert skalieren.

Beides ist mit vernünftigen Passwort und nur Bf kaum zu knacken, aber beim WI sieht die Dauer die man da durchschnittlich für brauchte deutlich schlimmer aus.

@DaVu bei docker ist es nur dann so, wenn du dem docker die Partition gibst. Ich würde einem docker niemals /etc geben

Dateizugriff aus docker entweder auf bestimmte Verzeichnisse oder über cifs/smb

Wer hat den hier die Buch- Rechte ander Diskussion?