8:59
1/6/2016

* Wyciek z serwisu scrum.org

Użytkownicy serwisu otrzymują takie wiadomości:

We value you as a customer of Scrum.org and respect the privacy of your information. This is why, as a precautionary measure, we are writing to let you know about a security incident which involves your personal information. This notice has not been delayed due to a law enforcement investigation.

What Happened?

On May 26, 2016, we noticed an issue with the Scrum.org website outgoing mail server. Upon investigation, we determined that emails used to communicate initial passwords were not being sent. After further investigation, our information technology professionals discovered that some of our mail server settings had been modified and found one new administrator user account. The very next day, we were informed by one of our software vendors that we use to operate the website that their software contained a newly discovered vulnerability, which accounted for the issues we had seen. We immediately confirmed the applicability of the vulnerability and followed all of our vendor’s instructions to ensure the vulnerability was resolved.

What information Was Involved?

While we continue to investigate the matter, we have determined that user’s names, email addresses, encrypted passwords, the password decryption key, and completed certifications and their associated test scores may have been compromised, but at this time we are not able to confirm that any of these items were actually taken, nor is there any evidence that any of this information was used by an unauthorized individual. User’s profile photographs, if uploaded, may also have been compromised. We do not store any other information on our servers. No financial information was involved in this incident.

What We are Doing

In addition to closing the vulnerability as directed by our vendor and deleting the invalid administrator account, we have reset the passwords of all Scrum.org accounts. To continue accessing your account, you will be required to set a new password at your next login. This summer, we are also moving to a new software vendor that provides greater password security.

What You Can Do

If you wish to continue accessing your Scrum.org account, you will be required to change your Scrum.org password. If you use the same or similar passwords on other online services, we recommend that you set new passwords on those accounts as well.

For More Information

If you have any questions, please feel free to contact us at breachinfo@scrum.org.

Thank you,

Dave West
CEO
Scrum.org

Dobrze, żę szyfrowali hasła. Szkoda, że klucz deszyfrujący wyciekł razem z zaszyfrowanymi hasłami. Innymi słowy, upewnijcie się, że Wasi PM nie mają takich samych haseł w innym miejscu…

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

5 komentarzy

Dodaj komentarz
  1. Niestety masa ludzi w sytuacji takiej jak ja, może nie otrzymać informacji o wycieku. W serwisie scrum.org miałem konto założone na email swojego byłego pracodawcy. Pracę zmieniłem, do emaila nie mam już dostępu. Jakby nie Niebezpiecznik nie dostałbym informacji o wycieku danych :)

  2. no chyba niezbyt dobrze, że szyfrowali hasła – powinni trzymać tylko hash’e

    • Być może trzymali hash+sól, ale w procesie upraszczania szczegółów technicznych opis zmienił się na zaszyfrowane hasło i klucz.

    • No albo trzymali posolone hashe, które dodatkowo postanowili zaszyfrować by uniknąć ataków na nie. W sumie dobra metoda.
      Tak się zastanawiam, czy dobrą praktyką byłoby do kodu źródłowego backendu, który potem byłby kompilowany do binarki “wszyć” pod jakąś stałą klucz.
      Wtedy programista na localu ma do tego dostęp, a po zrobieniu builda wszystko jest w binarce i wykradnięcie klucza jest mocno utrudnione- trzeba wykraść dodatkowo binarke i zrobić reverse engineering.

  3. @Majk:
    Nie wydaje mi sie, zeby to byla dobra praktyka. Reverse engineering tego bylby stosunkowo prosty, a kod zrodlowy jest dodatkowym miejscem z ktorego klucz moze wyciec.
    Osobiscie nie chcialbym, zeby junior dev, ktory zostal zatrudniony powiedzmy tydzien temu mial do dostep do takiego klucza (jak i do produkcyjnego serwera), dlatego sklanialbym sie do trzymania klucza w zmiennej srodowiskowej – dev ma swoj lokalny klucz wykorzystywany z jego lokalna baza danych, produkcyjny klucz jest dostepny dla zaufanych adminow.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.