Replit waarschuwt gebruikers dat personeel toegang tot plaintext wachtwoorden had
Softwareontwikkelplatform Replit heeft gebruikers gewaarschuwd dat medewerkers toegang tot hun plaintext wachtwoorden hadden. In een e-mail aan klanten laat het bedrijf weten dat het onlangs een 'beveiligingsconfiguratieprobleem' ontdekte waardoor Replit-medewerkers toegang hadden tot de plaintext wachtwoorden van een 'klein aantal' Replit-gebruikers. Om wat voor probleem het precies gaat en het aantal getroffen klanten zijn niet bekendgemaakt.
Replit zegt geen aanwijzingen te hebben dat er misbruik van het probleem is gemaakt. Uit voorzorg adviseert het bedrijf gebruikers om hun wachtwoord te wijzigen en dit ook te doen voor andere diensten waar hetzelfde wachtwoord wordt gebruikt. Replit biedt een platform voor het ontwikkelen en uitrollen van software. Het bedrijf claimt meer dan dertig miljoen gebruikers te hebben.
Reacties (11)
onlangs een 'beveiligingsconfiguratieprobleem' ontdekte waardoor Replit-medewerkers toegang hadden tot de plaintext wachtwoorden
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
Mee eens. Als Replit gevoelige persoonsgegevens zou verwerken, dan kan de AP een fikse boete uitschrijven wegens grove nalatigheid. Nu kan je alleen maar aannemen dat Replit het niet zo erg vind *wanneer* de systeemontwikkeling van haar klanten in gevaar komt.
Door Anoniem:
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
onlangs een 'beveiligingsconfiguratieprobleem' ontdekte waardoor Replit-medewerkers toegang hadden tot de plaintext wachtwoorden
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Door Anoniem: Mee eens. Als Replit gevoelige persoonsgegevens zou verwerken, dan kan de AP een fikse boete uitschrijven wegens grove nalatigheid. Nu kan je alleen maar aannemen dat Replit het niet zo erg vind *wanneer* de systeemontwikkeling van haar klanten in gevaar komt.
Dit soort configuraties maakt de gevaren van een "supply chain attack" aanzienlijk groter voor de klanten van de Replit klanten. Je zou 2FA verplicht moeten stellen voor online ontwikkelomgevingen.Door Anoniem:
Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Door Anoniem:
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
onlangs een 'beveiligingsconfiguratieprobleem' ontdekte waardoor Replit-medewerkers toegang hadden tot de plaintext wachtwoorden
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Zeg Kerstman (Hoho), klopt dat je niet te snel conclusies moet trekken, maar de tekst is toch duidelijk?
toegang hadden tot de plaintext wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!Door Anoniem: Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Dat de toegang tot de plaintext-wachtwoorden van een klein aantal gebruikers zou zijn geweest maakt een dergelijk scenario inderdaad waarschijnlijker dan dat ze alle wachtwoorden plaintext opslaan en dat medewerkers daar toegang toe hadden.Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Vraag me af of er met deze paswoorden toegang was tot de signing keys van de software van ontwikkelaars, want dan kunnen blackhats malafide software ondertekenen en uitrollen onder de massa's.
Zaten er overheidsprojecten bij de software van de gehackte ontwikkelaars?
Een hoop onzekerheid.
Zaten er overheidsprojecten bij de software van de gehackte ontwikkelaars?
Een hoop onzekerheid.
06-11-2024, 17:03 door
majortom
Door Anoniem:
Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Hoop niet dat ze de passwords loggen. Dan zou het probleem nog wel eens groter kunnen zijn dan verwacht.Door Anoniem:
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
onlangs een 'beveiligingsconfiguratieprobleem' ontdekte waardoor Replit-medewerkers toegang hadden tot de plaintext wachtwoorden
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
06-11-2024, 17:55 door
Briolet
Door Anoniem: …Zeg Kerstman (Hoho), klopt dat je niet te snel conclusies moet trekken, maar de tekst is toch duidelijk?
toegang hadden tot de plaintext wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!Er staat zeker niet dat de wachtwoorden plain-text opgeslagen waren. Als dat zo was zou je verwachten dat medewerkers bij de wachtwoorden van alle gebruikers konden komen. (Zoals ook anoniem van 14.22 uur aanneemt)
Het lijkt waarschijnlijkere dat de plaintekst wachtwoorden bij de verwerking van de inlog ergens onbewust opgeslagen worden.
Bij een goede inlog procedure zou het wachtwoord als cliënt side gehashed moeten worden en dan nog een keer gehashed met de session key. Dan wordt de ramp ook minder groot als er toch per ongeluk iets in een log komt.
Door Anoniem:
Zeg Kerstman (Hoho), klopt dat je niet te snel conclusies moet trekken, maar de tekst is toch duidelijk?
Door Anoniem:
Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Door Anoniem:
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
onlangs een 'beveiligingsconfiguratieprobleem' ontdekte waardoor Replit-medewerkers toegang hadden tot de plaintext wachtwoorden
Dat is niet één beveiligingsprobleem maar in ieder geval 2:
1- Medewerkers kunnen bij plain-text wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!
Advies is om het wachtwoord te wijzingen, waarna deze weer plain-text opgeslagen wordt!?!?!? Nu nog even wachten totdat een kwaadwillende binnenkomt en de wachtwoorden as-is meeneemt.
Hoho, niet zo snel conclusies trekken.
Het zou bijvoorbeeld ook kunnen dat wachtwoorden bij wijziging ergens gelogd werden, bijvoorbeeld als onderdeel van een webserver log waar ze bijvoorbeeld in de URL terecht komen.
Het zou kunnen dat (een deel van de) medewerkers bij de logs kunnen komen en daardoor (een deel van) de wachtwoorden konden zien, terwijl in de database de wachtwoorden keurig gehashed zijn.
Zeg Kerstman (Hoho), klopt dat je niet te snel conclusies moet trekken, maar de tekst is toch duidelijk?
toegang hadden tot de plaintext wachtwoorden
2- Wachtwoorden staan plain-text opgeslagen!Toegang hebben tot plain-text wachtwoorden betekend niet persé dat ze als plain-text in de database opgeslagen stonden.Hohohoho
07-11-2024, 15:58 door
Briolet
Toegang hebben tot plain-text wachtwoorden betekend niet persé dat ze als plain-text in de database opgeslagen stonden.Hohohoho
Precies. Het is bij mij b.v. een keer misgegaan bij een sudo commando in een bash sessie waarbij ik niet goed oplette en de fout in het sudo commando niet opmerkte. Uit routine tikte ik erna het wachtwoord in en pas na de return merkte ik dat mijn wachtwoord plaintekst in beeld stond omdat ik niet in de sudo routine zat.
Gelukkig realiseerde ik me dat bash alle input op de server logt en ik gelukkig toegang tot dat server-log had. Dus heb ik snel weer mijn wachtwoord uit het logbestand ge-edit.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?