Bit.ly is mogelijk getroffen door hack

Linkverkorter Bit.ly is mogelijk getroffen door een hack. Uit voorzorg heeft het bedrijf alle koppelingen met Twitter- en Facebook-accounts ongeldig gemaakt. Gebruikers wordt aangeraden om hun wachtwoord voor de dienst te wijzigen.

Details van de mogelijke hack zijn niet bekend; Bit.ly schrijft enkel dat het 'reden heeft om te denken dat logingegevens zijn gecomprommitteerd'. Welke logingegevens de aanvallers hebben gekregen en of het bijvoorbeeld gaat om al dan niet versleutelde wachtwoorden, blijkt echter niet uit de verklaring van Bit.ly.

De linkverkorter raadt gebruikers in ieder geval aan om hun wachtwoorden te wijzigen, ondanks dat er 'geen indicatie' is dat de aanvallers ook daadwerkelijk toegang hebben gehad tot accounts van gebruikers. Daarnaast zijn gelinkte Twitter- en Facebook-accounts uit voorzorg ontkoppeld en raadt Bit.ly gebruikers ook aan om hun api-key te wijzigen. De api kan worden gebruikt om vanuit externe apps link te verkorten; door een account te linken kunnen gebruikers zien hoe vaak hun links zijn aangeklikt.

Reacties (47)

[twkr18526]

Voor een tijd dacht ik dat het makkelijk was om een bitly account aan te maken met twitter en fb, maar als je de laatste berichtgevingen leest vraag ik me wel af of het juist handiger is om je voor iedere dienst apart aan te melden.

Het makkelijk aanmelden voor andere diensten als bitly dmv je twitter of fb account geeft je dan extra zorgen. Moet ik m'n twitter wachtwoord nu veiligheidshalve gaan veranderen?

[Reactie gewijzigd door twkr18526 op 23 juli 2024 15:33]

[Xatom]

Nee, je logt in via Twitter, dus je stuurt je wachtwoord alleen naar Twitter.

De communicatie tussen Bit.ly en Twitter gaat dan via een gegenereerde sleutel, die bevat niet jouw wachtwoord en kan alleen worden gebruikt in combinatie met de private key (API key) van Bit.ly.

[Verwijderd]

Hoe kan ik die blauwe waarschuwingsbalk boven aan bitly weg krijgen?

moet ik mijn twitter & facebook account ontkoppellen ?

APIKey op bitly heb ik gerest maar de blauwe balk met de waarschuwing blijft staan.

hoe krijg ik die weg? :-)

[Kevinp]

Wat dacht je van gewoon normale links gebruiken. Bij twitter ok, maar in alle andere gevalen wil ik graag zien waar ik naar toe ga.

[twkr18526]

Ik begrijp je punt. Heb ik ook, maar zelf vind ik het handiger om korte links te gebruiken als ik een url naar iemand stuur via SMS/Whatsapp/iMessage.

[Giftcard]

Helemaal mee eens..
Zeker in deze tijd waar iedereen over elkaar heen rolt als het het woord security valt, gaat het mijn pet te boven dat men zonder vragen te stellen op links klikt waaraan je onmogelijk kan zien waar deze je naar toe brengt..

Anyway, ontopic:
Hopelijk maken ze snel duidelijk waar de exacte hack is gedaan, ik blijf het een slechte zaak vinden dat ze niet meteen meer openheid geven..
Het hoeft niet 100% te zijn, maar iets meer dan: "We hebben iets gezien, we zeggen niet wat, maar verander voor de zekerheid je wachtwoord ff.." zou toch wel fijn zijn.

[Kalief]

Dat kan vaak helemaal niet. Bijvoorbeeld als je in een berichtje ook een link wilt posten dan moet het cms snappen waar jouw url begint en ophoudt. Als er allerlei references en parameters in de url zitten kan die onbegrijpelijk worden voor het cms waardoor die de url bijvoorbeeld afbreekt bij een ? of # of , . Een linkverkorter omzeilt dit probleem.

[bbr]

Ik click ook echt nooit bit.ly of andere short urls aan omdat 9/10 keer er een virus url achter zit.

[himlims_]

maak ook gebruik van single-signon op mijn website; nergens worden dat soort gegevens bij mij opgeslagen

[Verwijderd]

Nee je Twitter wachtwoord hoef je niet te niet te veranderen, dat staat in de bron als je doorklikt in het artikel: "We invalidated all credentials within Facebook and Twitter.."

[GabrielWB]

Ik blijf toch altijd een dubbel gevoel hebben bij linkverkorters.
Het is inderdaad handig als je gebonden bent aan een limiet aan de lengte van een post (Twitter bijvoorbeeld) en vaak ziet het er gewoon een stuk netter uit. Maar als een dienst een keer uitvalt of zijn database corrupt raakt dan zit je ineens met een gigantische berg aan ongeldige links verspreid over het hele internet.

[raptorix]

Klopt, wat natuurlijk een optie is dat je je eigen urlshortener gebruikt, uiteraard kan die ook een keer corrupt raken, maar dan heb je in ieder geval nog een optie van backup. Overigens zijn shorteners ook nog eens heel nuttig om bijvoorbeeld inkomend verkeer te meten, aangezien Twitter https is, zie je dat in je statistieken niet terug omdat https geen refferer meegeeft in de headers.

[JKP]

Die stelling van je klopt denk ik niet (of je bedoeld iets anders). De links die Dropbox produceert zijn namelijk HTTPS links. Toch was er een referral header die meegestuurd werd. Verder zijn er genoeg andere dingen die achter een SSL certificaat/verbinding staan, maar waar het inkomend verkeer wel degelijk gemeten wordt. Neem bijv. GMail, banken etc. Die kunnen echt wel zien wat er aan verkeer binnenkomt.

[Reactie gewijzigd door JKP op 23 juli 2024 15:33]

[raptorix]

"If a website is accessed from a HTTP Secure (HTTPS) connection and a link points to anywhere except another secure location, then the referer field is not sent"

Bron: http://en.wikipedia.org/wiki/HTTP_referer#Referer_hiding

[Tonko Boekhoud]

Dat klopt niet helemaal, de standaard zegt dat https geen referrer zou moeten geven.
Het is dus niet onmogelijk om referrers mee te geven, het ligt aan de implementatie van de standaard.

Bron http://www.w3.org/Protoco...2616-sec15.html#sec15.1.3

[Verwijderd]

Ik denk ook dat je als vuistregel moet hanteren, dat als je duurzaam aan iets wilt linken dat je dan de originele URL gebruikt als verwijzing. Gaat het om iets minder belangrijks, iets op incidentele basis of korts, dan is een URL-verkorter een prima alternatief. Dus eigenlijk is het niet zo moeilijk toch.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 15:33]

[m8ZBm1Si]

Het is ondertussen niet meer interessant om url-shorteners te gebruiken. Twitter verkort ze ondertussen automatisch, waardoor ze niet meer je hele tweet innemen.

De enige reden om dit wel te gebruiken, zou statistieken kunnen zijn, maar hiervoor wordt het bijna niet meer gebruikt.

[Kalief]

Alsof linkverkorters alleen bestaan bij gratie van Twitter
Ze zijn noodzakelijk in alle gevallen waar je geen html of bbcode kunt gebruiken, een cms de link kan vernaggelen of in een uitleggende tekst waar een url niet de flow van de tekst mag doorbreken.

[WokeBroke]

Google weet eventueel ook nog wel waar alle bit.ly links heen gaan

[Verwijderd]

Geen idee waarom je een -1 krijgt. Een zoekmachine indexeerd die informatie namelijk gewoon waardoor je opmerking terecht is.

[biglia]

Maar als bit.ly bijvoorbeeld niet meer werkt zoals Gabriel_WB aangeeft, dan klik je op een bit.ly link en krijg je geen antwoord meer. Dus wat ben je dan met Google?

Sowieso lijkt het me riskant om een .ly domein hiervoor te gebruiken.

[biglia]

Het is wel leuk dat die linkverkorters statistieken bijhouden. Als je bij bit.ly een '+' - teken achter de url plaatst, kan je dat zien. Dat lijkt me handig voor twitteraars met veel volgers. Het nadeel is dat iedereen die statistieken kan opvragen, en bij accounts met veel volgers vallen die vaak serieus tegen.

[MrMonkE]

Nog nooit zo over nagedacht maar daar heb je wel een punt. Sowieso kom ik met gewone links ook al vaak genoeg '404' tegen maar als dit soort diensten failliet gaat dan is er wel een hele berg aan 404 opeens. Een beetje als met die fileshare/upload sites als megaupload.
Dus als commercieele partij zou je eigenlijk gewoon in-house zo'n ding moeten draaien.

[Verwijderd]

De grootste ICT-problemen waar ik in mijn leven mee te maken heb gehad waren altijd het gevolg van in-house problemen. Dat is dus niet zaligmakend.

[Verwijderd]

Archive.org is al bezig met het archiveren van verkorte URL's: http://archiveteam.org/index.php?title=URLTeam

[vssr]

Ben het met je eens, ergens smaakt het naar bad-practice. Wat me vooral stoort: HTML heeft voor weergave doeleinden al sinds jaar en dag een 'url-shortener' ingebouwd. Je stopt de daadwerkelijke link in het <a href="" attribuut, en je 'shortener-text' tussen <a href="#"> en </a>. Of voor de niet-HTML'ers, zoals op Tweakers en vele andere websites wordt gedaan, met een mooi 'link invoegen' knopje. Het kan zo simpel zijn...

[Verwijderd]

Afgezien van gebruik in Twitter heb ik nooit de populariteit van shorteners begrepen:

- Afhankelijkheid van een derde partij, geen controle meer over je links, waardoor ze bij incidenten ineens broken zijn. Weg verkeer.

- Je geeft de derde partij gratis en voor niets detail-inzicht in je verkeer

- Buiten Twitter om is er geen enkele noodzaak voor, en ze zien er niet uit.

[JKP]

Helemaal mee eens wat je zegt. Het is inderdaad een overbodig iets, met mijns inziens veel nadelen en weinig of misschien zelfs geen voordelen. Afgekorte links wantrouw ik zo ie zo altijd. Je weet niet waar je terecht komt als je erop klikt.

Overigens is het zelfs op Twitter niet eens een bitter noodzaak om ze te gebruiken. Je kan je bericht eventueel opdelen in twee keer 140 tekens.

[Droefsnoet]

Overigens is het zelfs op Twitter niet eens een bitter noodzaak om ze te gebruiken. Je kan je bericht eventueel opdelen in twee keer 140 tekens.

maar het is tegen de tweetiquette om berichten op te delen

[Verwijderd]

Je vergeet een punt:

- Ze kunnen gevaarlijk zijn, je weet immers niet op welke site je uit gaat komen tenzij je een URL-verlenger gebruikt.

[Verwijderd]

Goede aanvulling.

[Dr.Root]

Gelukkig, zodra ik een link van bit.ly zag klikte ik maar weer ''terug'' of zelfs weg. Voor de zekerheid mij wachtwoorden maar aangepast -.- Echter ben ik sowieso niet erg te spreken over link verkorters. Dat maakt het nog dubieuzer op welke site nu daadwerkelijk terrecht komt

Mijn Gateway Appliance (welke ik thuis heb staan) verbied het daarom ook om via verkorte links naar een bepaalde website te surfen. (Fortigate)

[Reactie gewijzigd door Dr.Root op 23 juli 2024 15:33]

[SJBijzitter]

Respect voor deze spoedige berichtgeving ook al is het niet zeker dat gegevens gestolen zijn! Mijn vertrouwen is (raar genoeg?) alleen maar toegenomen.

[WokeBroke]

Over 10 jaar zijn computers zo snel dat we kunnen brute forcen met een random fingerprint generator.

[MrMonkE]

Na elke 3e mislukte actie moet jij 5 seconden wachten.
Zo simpel doen we dat.

Veel success met je Brute Force.

[JKP]

Verhoog die 5 seconden dan gelijk naar 60 minuten . Nog beter zou zijn dat de tijd die je moet wachten, voor een nieuwe poging random is. Anders zou je de bruteforce daar nog op aan kunnen passen.

Overigens is de kans dat iemand 3 keer iets verkeerd invult klein. Gebeurd dat wel, dan is er meestal sprake van het vergeten zijn wachtwoord/pincode. Een ander verhaal is natuurlijk dan weer de vingerafdruk.

[Verwijderd]

Asjeblieft niet. Voorbeeld: ik moet met regelmaat iDeal implementeren op een website, en vaak krijg je de logingegevens fout aangeleverd of zijn ze geschreven. Vooral de wachtwoorden van de Rabobank Omnikassa zijn een hell wanneer je ze niet kunt kopieren/plakken.

Komt dus regelmatig voor dat ik 5 pogingen nodig heb, en er dan nog niet in zit. Zou ik een uur moeten wachten raad ik mijn klanten de Rabobank standaard af.

Wat beter zou zijn (denk ik) is die 5 seconde aanhouden, en bij iedere throttle binnen het uur die 5 seconde tijd steeds langer maken met een x-aantal secondes (waarvan de x variable is). Dan heb je niet zomaar een makkelijk te bruteforcen systeem en hou je het toch nog gebruiksvriendelijk.

[Huugje]

Kun je dan niet beter het probleem aanpakken van het fout en/of onleesbaar aanleveren van de login gegevens? Je kunt nu wel een bank gaan afraden bij je klanten, maar daar ligt het probleem blijkbaar niet.

[Verwijderd]

Nee, het probleem ligt bij de klanten, dat klopt. Maar wanneer 99% van de klanten het toch niet goed kan aanleveren zit het probleem ergens daar

Daarnaast heb je meestal 2 omgevingen bij iDeal, test en productie. Laten ze nu net die 2 nooit synchroniseren -_-

[YopY]

5 seconden of exponentieel; dat, of account locken na 3 mislukte pogingen. Two-factor authentication werkt ook goed.

[ILUsion]

Account locken na X slechte pogingen is al helemaal problematisch: om een Denial Of Service-aanval uit te voeren, heeft een hacker dus enkel je login-naam nodig en probeert hij maar vaak genoeg in te loggen. Je verheft de gebruikersnaam dan bijna tot status van wachtwoord: iets dat je geheim moet houden. In systemen waar je e-mail je login is (of er sterk op lijkt), heb je dan een groot probleem.
En na zo'n aanval kan jij de hele papiermolen in gang trekken om je account weer in werking te stellen en dan kan het spelletje weer van voor af aan beginnen.

Doe mij dan liever een IP-block na X slechte pogingen en vooral two-factor authentication. Dat maakt het al vrij onwaarschijnlijk dat iemand op je account binnen geraakt of geblokkeerd krijgt.

[wica]

Doe je dat per account of per IP?
Toe zeg per account

[MrMonkE]

Ja, per account natuurlijk. Dan kun je maximaal 2160x per uur brute forcen.
Je kan natuurlijk ook staffelen.
3x fout 5, 6x fout 10, 9x fout 15, 12x fout 25, 15x fout 30, etc

[wica]

Ik zou toch echt op basis van ip en account een straftijd er opzetten. Anders kan het voorkomen, dat iemand door middel van een brute force attack, het onmogelijk kan maken voor een ander om gebruik te maken van je systeem.

Maar verder kan je gerust aannemen, als je op een account, 6 mislukte inlog pogingen hebt. Dat iemand het account probeerd te hacken, dus het betreffende IP voor een uur of langer in blokken.

Maar wat is je site?

[_Dune_]

Fingerprint readers van nu zijn al geen super goede beveiliging, er zijn de afgelopen paar jaar al mooie voorbeelden geweest dat het makkelijk is een fingerprint te kopiëren. Dat zal het dan ook niet echt worden.