Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Password Hashing Competition…
  6. Them…

Weitere Anforderung: Sichere Authentifizierung

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 14:02

    rngcntr schrieb:
    --------------------------------------------------------------------------------
    > bjs schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das Problem ist, dass das Passwort bzw. ein Äquivalent des Passwortes am
    > > Server im Klartext gespeichert werden muss.
    >
    > Aber wozu? Der Server braucht doch nicht mehr als den Hash des Passworts.
    > Meinst du das mit einem Äquivalent?
    Genau das meine ich. Das Äquivalent reicht aus, um sich zu authentifizieren.

  2. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 14:20

    Marc2 schrieb:
    --------------------------------------------------------------------------------
    > aber ein serverdatendieb macht den wörterbuchangriff bei srp doch in der
    > gleichen zeit wie üblich, oder?
    Es gibt im Prinzip drei Arten der passwortbasierten Authentifizierungsverfahren:

    - Klartext im Transport, Hash in der Datenbank
    - Hash im Transport, Klartext (oder Äquivalent) in der Datenbank
    - Hash (oder etwas ähnliches) im Transport UND und der Datenbank.

    Die SASL-Methoden PLAIN und LOGIN (wobei das keine offizielle SASL-Methode ist) und die Basic-Authentifizierung von HTTP, wie auch alle Arten der Authentifizierung per HTML-Formular sind Verfahren der ersten Art. Die Digest Authentifizierung bei HTTP, DIGEST-MD5, CRAM-MD5, SCRAM-SHA1 usw. sind alle mehr oder weniger Methoden der zweiten Art, wobei SCRAM-SHA1 noch etwas komplizierter ist und zumindest zwei Angriffe braucht.

    Die erste Art setzt einen sicheren Transport z.B. per TLS voraus. Die zweite eine sichere Speicherung der Passwörter. Bei der ersten Art kann sich jemand erfolgreich authentifizieren, wenn er den Transport mitliest. Bei der zweiten, wenn er die Datenbank ausliest. Bei SCRAM-SHA1 ist beides nötwendig, bei allen anderen Verfahren jeweils nur das entsprechende eine.

    Bei SRP, dem einzigen Verfahren der dritten Art, ist eine erfolgreiche Authentifzierung selbst dann nicht möglich, wenn Daten sowohl aus dem Transport als auch aus der Datenbank bekannt sind. Es ist damit das derzeit sicherste Verfahren, nur leider von kaum einer Software unterstützt. Für TLS gibt es übrigens eine Erweiterung für SRP. Leider wurde deren Implementierung in Libressl und auch bald bei OpenSSL abgeschafft.

  3. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: rngcntr 27.07.15 - 14:28

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Das Zauberwort heißt Challenge-Response. Das Verfahren wurde von einigen
    > bereits angesprochen. Der Server speichert einen (ggf. gesalteten)
    > Passworthash in der Datenbank. Bei der Authentifizierung schickt der Server
    > einen Zufallswert (Challenge) und ggf. den Salt an den Client, der Client
    > erzeugt aus dem Passwort und dem Salt den Passworthash, so wie er auch in
    > der Serverdatenbank liegt. Daraus wird mit der Challenge noch ein Hash
    > (Response) erzeugt und an den Server geschickt. Der Server muss ebenfalls
    > den Passworthash in der Datenbank mit der Challenge verquicken und das
    > Ergebnis mit der erhaltenen Response vergleichen.

    +1, das meinte ich ;)

    bjs schrieb:
    > Genau das meine ich. Das Äquivalent reicht aus, um sich zu
    > authentifizieren.

    Ich glaube so langsam komme ich dahinter. Du meinst, dass die Passwort+Salt Hashes auf dem Server liegen und jeder der sich Zugriff auf den Server verschaffen kann, damit auch das oben genannte Challenge Response Verfahren "umgehen" kann, stimmts?



    1 mal bearbeitet, zuletzt am 27.07.15 14:31 durch rngcntr.

  4. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 14:57

    @rngcntr schrieb:
    Ja, genau. Es reicht der Hash des Passwortes, ob mit oder ohne Salz, um das Verfahren erfolgreich abzuschließen. Das Klartextpasswort ist nicht notwendig. Der einzige Vorteil dabei ist nur, dass bei Bekanntwerden des Hashes nur dieser Account offen ist. Andere Accounts mit dem gleichen Klartextpasswort sind nach wie vor sicher, sofern ein gesalzener Hash verwendet wurde und das wie üblich das Passwort gut ist.

  5. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Marc2 27.07.15 - 15:24

    bjs schrieb:
    --------------------------------------------------------------------------------
    > Marc2 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > aber ein serverdatendieb macht den wörterbuchangriff bei srp doch in der
    > > gleichen zeit wie üblich, oder?
    > Es gibt im Prinzip drei Arten der passwortbasierten
    > Authentifizierungsverfahren:
    >
    > - Klartext im Transport, Hash in der Datenbank
    > - Hash im Transport, Klartext (oder Äquivalent) in der Datenbank
    > - Hash (oder etwas ähnliches) im Transport UND und der Datenbank.
    >
    > Die SASL-Methoden PLAIN und LOGIN (wobei das keine offizielle SASL-Methode
    > ist) und die Basic-Authentifizierung von HTTP, wie auch alle Arten der
    > Authentifizierung per HTML-Formular sind Verfahren der ersten Art. Die
    > Digest Authentifizierung bei HTTP, DIGEST-MD5, CRAM-MD5, SCRAM-SHA1 usw.
    > sind alle mehr oder weniger Methoden der zweiten Art, wobei SCRAM-SHA1 noch
    > etwas komplizierter ist und zumindest zwei Angriffe braucht.
    >
    > Die erste Art setzt einen sicheren Transport z.B. per TLS voraus. Die
    > zweite eine sichere Speicherung der Passwörter. Bei der ersten Art kann
    > sich jemand erfolgreich authentifizieren, wenn er den Transport mitliest.
    > Bei der zweiten, wenn er die Datenbank ausliest. Bei SCRAM-SHA1 ist beides
    > nötwendig, bei allen anderen Verfahren jeweils nur das entsprechende eine.
    >
    > Bei SRP, dem einzigen Verfahren der dritten Art, ist eine erfolgreiche
    > Authentifzierung selbst dann nicht möglich, wenn Daten sowohl aus dem
    > Transport als auch aus der Datenbank bekannt sind. Es ist damit das derzeit
    > sicherste Verfahren, nur leider von kaum einer Software unterstützt. Für
    > TLS gibt es übrigens eine Erweiterung für SRP. Leider wurde deren
    > Implementierung in Libressl und auch bald bei OpenSSL abgeschafft.

    Hey, danke für diese Erklärung!

    Ich schließe daraus, dass bei Bekanntsein der Serverdaten (inklusive Salts) ein Wörterbuchangriff auf das Passwort logischerweise immer möglich ist, und die Frage danach sich erübrigt. Die Frage schießt ja über die Abwehr von Replay-Attacken hinaus.

    Auf dem Server den "verifier" v = pow(2, x, N) zu speichern, siehe englischer Wikipedia-Eintrag zu SRP, muss wohl dem Diffie-Hellman-Teil geschuldet sein. Ich dachte nämlich zuerst, das wäre eine exotische Möglichkeit, jeglichen Wörterbuchangriffen zu entgehen. Aber dem ist nicht so, weil N in den Serverdaten ist, und zudem schreibt Wikipedia, dass es eine gute Passworthashfunktion "highly recommended" ist.

    Und ich schätze dann mal, dass ein Schlüsseltauschverfahren innerhalb einer ohnehin hergestellten Https-Verbindung "doppelt gemoppelt" zwar besser hält, aber von den SSL-Machern evtl. mit dem Argument rausgeschmissen wird, dass ihr Transport ja alleine schon sicher sein will.

  6. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 17:00

    Bei passwortbasierten Verfahren ist sowas immer möglich, da die ganze Sicherheit ja von der Qualität des Passwortes abhängt. Schlussendlich kann man ja auch einfach andauernd neue Verbindung zum Server aufbauen und alle Passworte durchprobieren. Der Server sollte dies dann verhindern. Wenn der Hash des Passwortes bekannt ist, ist kein Server da, um dies zu verwenden.

    SRP verwendet bekannte kryptographische Algorithmen. Wenn diese unsicher sind, ist auch SRP unsicher. Das gilt aber für jedes Authentifzierungsverfahren. Auch die Authentifizierung mit TLS-Client-Zertifikaten hängen von der Sicherheit von z.B. RSA ab.

    Es gab niemanden, der sich um den Code gekümmert hat, und SRP hat ganz einfach niemand verwendet in Kombination mit TLS. Die Kerberos-Authentifizierung bei TLS hat das gleiche Schicksal. TLS mag wirklich die falsche Schicht sein für SRP, aber IMAP, SMTP, XMPP, HTTP usw. könnten problemlos damit authentifiziert werden. Hier fehlt nur die Unterstützung in den einzelnen Clients und Servern.

  7. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: JP 27.07.15 - 17:05

    Wie wärs damit, komplett auf Passwort-Authentifizierung zu verzichten? Habe mal vor Jahren einen Vorschlag zum passwortlosem Login gelesen. Dabei meldet sich jemand mit seiner e-mail Adresse an, bekommt einen Aktivierungslink über das der Nutzer dann eine langlebige Session gesetzt bekommt. Wenn das E-Mail Konto eines Nutzers kompromittiert ist, ist so oder so alles zu spät und die Defakto Identität des Nutzers verloren.

    Vorteil an dem Verfahren ist:
    - Wir müssen gar keine Passwörter speichern
    - Nutzer muss sich kein PW merken und wird nicht genötigt ein bereits verwendetes Passwort bei uns einzugeben

    Nachteile:
    - Wir haben jahrelang Surfer dazu erzogen, dass nur PW sicher sind. Der Verzicht auf ein Passwort wird garantiert als unsicher empfunden.
    - die Session muss entsprechend abgesichert werden (sollte sie so oder so)

    Irgendwelche technischen bedenken?

  8. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: lestard 27.07.15 - 17:31

    Was ist denn der Grund, warum sich das nicht durchsetzt obwohl es den anderen Verfahren gegenüber überlegen ist?

  9. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 17:36

    lestard schrieb:
    --------------------------------------------------------------------------------
    > Was ist denn der Grund, warum sich das nicht durchsetzt obwohl es den
    > anderen Verfahren gegenüber überlegen ist?
    Niemand hat es implementiert. cyrus-sasl unterstützt es, glaube ich. Aber kein einziger Client.

  10. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Marc2 27.07.15 - 17:47

    JP schrieb:
    --------------------------------------------------------------------------------
    > Wie wärs damit, komplett auf Passwort-Authentifizierung zu verzichten? Habe
    > mal vor Jahren einen Vorschlag zum passwortlosem Login gelesen. Dabei
    > meldet sich jemand mit seiner e-mail Adresse an, bekommt einen
    > Aktivierungslink über das der Nutzer dann eine langlebige Session gesetzt
    > bekommt. Wenn das E-Mail Konto eines Nutzers kompromittiert ist, ist so
    > oder so alles zu spät und die Defakto Identität des Nutzers verloren.
    >
    > Vorteil an dem Verfahren ist:
    > - Wir müssen gar keine Passwörter speichern
    > - Nutzer muss sich kein PW merken und wird nicht genötigt ein bereits
    > verwendetes Passwort bei uns einzugeben
    >
    > Nachteile:
    > - Wir haben jahrelang Surfer dazu erzogen, dass nur PW sicher sind. Der
    > Verzicht auf ein Passwort wird garantiert als unsicher empfunden.
    > - die Session muss entsprechend abgesichert werden (sollte sie so oder so)
    >
    > Irgendwelche technischen bedenken?

    bei apps wäre es schön, wenn man nicht vor programmier-hürden stände, aus dem link eine session in der app statt im browser zu machen. ich habe eine kleine spaß-app, bei der ich "passwortlosen" zugang anbiete, in der form eines generierten "passworts" dessen komplexität (immerhin 8 abzutippende zeichen/buchstaben) eher dem von dir genannten vorschlag ähnelt als dem "user denkt sich passwort aus."

    blöd finde ich, dass
    - ich bis jetzt nicht geguggt hab, ob mein system("echo hier dein tokenpasswortblubb | mail") wirklich tls verbindung (hallo nsa) auslöst, müsste ich mal tun
    - ich nicht weiss, welche mail anbieter oder user tls einsetzen
    - mailinhalte generell als input für kontextsensitive werbung dienen
    - cryptomailinhalte vom bildschirm ablesbar sind (insbesondere mein 8stellen-passwort)
    - ich nicht weiss, wo ich bei nem mail-sende-vorgang die entropie ausnullen kann (serverhack => speicherdump => cryptozeugs steht drin, sessionlink wurde vom user noch nicht angeklickt => problem)

    aber ich find das schema bzw den gedankengang via e-mail gut, besser gesagt, es ist mein favorit

  11. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: robinx999 27.07.15 - 17:54

    Langlebige Session stimmt mich schon kritisch. Klar man kann im Browser einen Cookie setzen mit dem sich der Nutzer dann identifiziert, aber trotzdem Problematisch wenn eine andere Person an den Rechner kommt. Generell bei der höheren Anzahl an Geräten sicherlich problematisch. Und die Option Cookies beim Beenden zu löschen macht das ganze System extrem problematisch, wenn der Nutzer so etwas gesetzt hat.

  12. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: lestard 27.07.15 - 18:10

    mhh naja aber warum hat es denn keiner Implementiert wenn es besser als das andere ist? Weils niemand kannte oder zu kompliziert oder hat es irgendwelche anderen Nachteile? Oder gibts keinen ersichtlichen Grund (was ja bei Technik-Kram durchaus vorkommt. Es setzt nicht nicht immer das beste durch)?

  13. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 18:20

    lestard schrieb:
    --------------------------------------------------------------------------------
    > mhh naja aber warum hat es denn keiner Implementiert wenn es besser als das
    > andere ist? Weils niemand kannte oder zu kompliziert oder hat es
    > irgendwelche anderen Nachteile? Oder gibts keinen ersichtlichen Grund (was
    > ja bei Technik-Kram durchaus vorkommt. Es setzt nicht nicht immer das beste
    > durch)?
    Weil für Ruhm, Ehre und Anerkennung in den Medien und aus der Benutzerschaft von neuen Klicki-Bunti-Features kommen und nicht von so profanen unsichtbaren Dingen wie Sicherheit.

  14. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: JP 27.07.15 - 18:36

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > Klar man kann im Browser
    > einen Cookie setzen mit dem sich der Nutzer dann identifiziert, aber
    > trotzdem Problematisch wenn eine andere Person an den Rechner kommt.

    Das ist aber nicht das Problem des Anbieters sondern des Nutzers. Das Problem gibt es auch, wenn der Nutzer Passwörter durch den Browser speichern lässt, oder sich vergisst aus seinem E-Mail Konto auszuloggen. Da ist es egal ob die Session nun 3 Minuten oder 30 Tage geht.

    Warum hat z.B. Chrome kein Master-Passwort für den Passwortmanager? Die Entwickler begründen es damit, dass es nur eine Pseudo-Sicherheit bringen würde, es wäre wichtiger dem Nutzer zu vermitteln, dass er den PC beim Verlassen sperrt, wenn andere Zugriff haben könnten.

    > Generell bei der höheren Anzahl an Geräten sicherlich problematisch. Und
    > die Option Cookies beim Beenden zu löschen macht das ganze System extrem
    > problematisch, wenn der Nutzer so etwas gesetzt hat.

    Jedes Gerät muss gesonders einmal aktiviert werden, unterscheidet sich kaum vom Passwort-Verfahren, bei dem sich der Nutzer auch auf jedem Gerät mindestens einmal einloggen muss. Und wenn der Nutzer Cookies bewusst beim Beenden löschen lässt, verhält sich das Passwortlose-Verfahren wie erwartet. Er müsste sich auch jedes mal neu einloggen, ob nun per E-Mail oder per Passwort, macht kaum einen Unterschied.

    Problematisch sehe ich daran nichts, außer, dass die Benutzererfahrung nicht ganz erwartungskonform ist, weil Nutzer zur pseudo-sicheren Passwörtern erzogen wurden.

  15. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Marc2 27.07.15 - 18:44

    JP schrieb:
    --------------------------------------------------------------------------------
    > robinx999 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Klar man kann im Browser
    > > einen Cookie setzen mit dem sich der Nutzer dann identifiziert, aber
    > > trotzdem Problematisch wenn eine andere Person an den Rechner kommt.
    >
    > Das ist aber nicht das Problem des Anbieters sondern des Nutzers. Das
    > Problem gibt es auch, wenn der Nutzer Passwörter durch den Browser
    > speichern lässt, oder sich vergisst aus seinem E-Mail Konto auszuloggen. Da
    > ist es egal ob die Session nun 3 Minuten oder 30 Tage geht.
    >
    > Warum hat z.B. Chrome kein Master-Passwort für den Passwortmanager? Die
    > Entwickler begründen es damit, dass es nur eine Pseudo-Sicherheit bringen
    > würde, es wäre wichtiger dem Nutzer zu vermitteln, dass er den PC beim
    > Verlassen sperrt, wenn andere Zugriff haben könnten.
    >
    > > Generell bei der höheren Anzahl an Geräten sicherlich problematisch. Und
    > > die Option Cookies beim Beenden zu löschen macht das ganze System extrem
    > > problematisch, wenn der Nutzer so etwas gesetzt hat.
    >
    > Jedes Gerät muss gesonders einmal aktiviert werden, unterscheidet sich kaum
    > vom Passwort-Verfahren, bei dem sich der Nutzer auch auf jedem Gerät
    > mindestens einmal einloggen muss. Und wenn der Nutzer Cookies bewusst beim
    > Beenden löschen lässt, verhält sich das Passwortlose-Verfahren wie
    > erwartet. Er müsste sich auch jedes mal neu einloggen, ob nun per E-Mail
    > oder per Passwort, macht kaum einen Unterschied.
    >
    > Problematisch sehe ich daran nichts, außer, dass die Benutzererfahrung
    > nicht ganz erwartungskonform ist, weil Nutzer zur pseudo-sicheren
    > Passwörtern erzogen wurden.

    ich weiss nicht ob ihr das meint, aber "Expire:" würde ich hier beim cookie setzen, und vielleicht den timeout erneuern bei gui-aktivität. oder macht man das anders? besser gesagt: browserschließen sollte die session killen, weil man das inzwischen gewohnt ist.

    ps: grad gemerkt, dass es der gmail session egal ist, ob ich das browserfenster schließe, funzt immer noch. aber das kann ja jeder halten wie er will, der forschritt ist wie JP sagt ja die abkehr vom user-passwort.



    2 mal bearbeitet, zuletzt am 27.07.15 18:52 durch Marc2.

  16. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: JP 27.07.15 - 18:52

    Marc2 schrieb:
    --------------------------------------------------------------------------------
    > ich weiss nicht ob ihr das meint, aber "Expire:" würde ich hier beim cookie
    > setzen, und vielleicht den timeout erneuern bei gui-aktivität. oder macht
    > man das anders? besser gesagt: browserschließen sollte die session killen,
    > weil man das inzwischen gewohnt ist.

    Joar über "Expire". Ich würde dann aber eher +30 Tage, evtl sogar länger (im Originalvorschlag waren es Jahre), beim Expire einstellen. Da darf man sich ja durch aus bei Google orientieren, dort muss man sich auch alle 30 Tage neu einloggen/authentifizieren. Dazwischen bleibt man eingeloggt, auch wenn der Browser geschlossen wird (außer man lässt natürlich die Cookies löschen). Häufiges immer wieder neu einloggen müssen macht Passwörter-Verfahren nicht unbedingt sicherer, eher im Gegenteil.

  17. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Marc2 27.07.15 - 18:54

    JP schrieb:
    --------------------------------------------------------------------------------
    > Marc2 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ich weiss nicht ob ihr das meint, aber "Expire:" würde ich hier beim
    > cookie
    > > setzen, und vielleicht den timeout erneuern bei gui-aktivität. oder
    > macht
    > > man das anders? besser gesagt: browserschließen sollte die session
    > killen,
    > > weil man das inzwischen gewohnt ist.
    >
    > Joar über "Expire". Ich würde dann aber eher +30 Tage, evtl sogar länger
    > (im Originalvorschlag waren es Jahre), beim Expire einstellen. Da darf man
    > sich ja durch aus bei Google orientieren, dort muss man sich auch alle 30
    > Tage neu einloggen/authentifizieren. Dazwischen bleibt man eingeloggt, auch
    > wenn der Browser geschlossen wird (außer man lässt natürlich die Cookies
    > löschen). Häufiges immer wieder neu einloggen müssen macht
    > Passwörter-Verfahren nicht unbedingt sicherer, eher im Gegenteil.

    stimmt. irgendwie ist der cookie timeout ein angst-reflex aus urzeiten ;)

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BWI GmbH, Hannover
  2. Hays AG, Hamburg
  3. Vodafone GmbH, Düsseldorf
  4. Hays AG, Nürnberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 49,70€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile-Games-Auslese: Superheld und Schlapphutträger zu Besuch im Smartphone
Mobile-Games-Auslese
Superheld und Schlapphutträger zu Besuch im Smartphone

Markus Fenix aus Gears of War kämpft in Gears Pop gegen fiese (Knuddel-)Aliens und der Typ in Tombshaft erinnert an Indiana Jones: In Mobile Games tummelt sich derzeit echte und falsche Prominenz.
Von Rainer Sigl

  1. Mobile-Games-Auslese Verdrehte Räume und verrückte Zombies für unterwegs
  2. Dr. Mario World im Test Spielspaß für Privatpatienten
  3. Mobile-Games-Auslese Ein Wunderjunge und dreimal kostenloser Mobilspaß

TVs, Konsolen und HDMI 2.1: Wann wir mit 8K rechnen können
TVs, Konsolen und HDMI 2.1
Wann wir mit 8K rechnen können

Ifa 2019 Die Ifa 2019 ist bezüglich 8K nüchtern. Wird die hohe Auflösung wie 4K fast eine Dekade lang eine Nische bleiben? Oder bringen kommende Spielekonsolen und Anschlussstandards die Auflösung schneller als gedacht?
Eine Analyse von Oliver Nickel

  1. Kameras und Fernseher Ein 120-Zoll-TV mit 8K reicht Sharp nicht
  2. Sony ZG9 Erste 8K-Fernseher werden bald verkauft
  3. 8K Sharp schließt sich dem Micro-Four-Thirds-System an

Serielle Hybride: Unterschätzte Zwischenlösung oder längst überholt?
Serielle Hybride
Unterschätzte Zwischenlösung oder längst überholt?

Die reine E-Mobilität kommt nicht so schnell voran, wie es Klimaziele und Luftreinhaltepläne erfordern. Doch viele Fahrzeughersteller stellen derweil eine vergleichsweise simple Technologie auf die Räder, die für eine Zukunft ohne fossile Kraftstoffe Erkenntnisse liefern kann.
Von Mattias Schlenker

  1. ADAC Keyless-Go bietet Autofahrern keine Sicherheit
  2. Gesetzentwurf beschlossen Regierung verlängert Steuervorteile für Elektroautos
  3. Cabrio Renault R4 Plein Air als Elektro-Retroauto

  1. Fiber To The Pole: Kabelnetzbetreiber für oberirdische Glasfaser
    Fiber To The Pole
    Kabelnetzbetreiber für oberirdische Glasfaser

    Glasfaser an den Masten sei die einzige Möglichkeit, die Ausbauziele der Bundesregierung noch zu erfüllen. Keinere Firmen sind von einem Vorstoß von Bundeskanzleramtsminister Helge Braun begeistert. Doch das hat auch Nachteile.

  2. Bayern: Mobilfunkversorgung an Autobahnen weiter lückenhaft
    Bayern
    Mobilfunkversorgung an Autobahnen weiter lückenhaft

    Bayern hat als erstes Bundesland selbst nachgemessen und herausgefunden, dass der LTE-Ausbau nicht den Auflagen entspricht. Am besten steht die Telekom da. Doch eigentlich hätte die Landesregierung gar nicht selbst messen müssen.

  3. Mixer: Microsoft integriert Werbebanner in seine Streamingplattform
    Mixer
    Microsoft integriert Werbebanner in seine Streamingplattform

    Es war nur eine Frage der Zeit: Microsoft blendet erste Werbebanner vor den Inhalten von Streamern wie Ninja auf Mixer ein. Das sei immer geplant gewesen, sagt das Unternehmen im Livestream. Allerdings erhält Microsoft wohl noch alle Einnahmen.


  1. 18:39

  2. 17:41

  3. 16:27

  4. 16:05

  5. 15:33

  6. 15:00

  7. 15:00

  8. 14:45