Researcher Finds Credentials for 92 Million Users of DNA Testing Firm MyHeritage



  • MyHeritage, an Israeli-based genealogy and DNA testing company, disclosed today that a security researcher found on the Internet a file containing the email addresses and hashed passwords of more than 92 million of its users.

    MyHeritage says it has no reason to believe other user data was compromised, and it is urging all users to change their passwords. It says sensitive customer DNA data is stored on IT systems that are separate from its user database, and that user passwords were “hashed” — or churned through a mathematical model designed to turn them into unique pieces of gibberish text that is (in theory, at least) difficult to reverse.

    MyHeritage did not say in its blog post which method it used to obfuscate user passwords, but suggested that it had added some uniqueness to each password (beyond the hashing) to make them all much harder to crack.

    “MyHeritage does not store user passwords, but rather a one-way hash of each password, in which the hash key differs for each customer,” wrote Omer Deutsch, MyHeritage’s chief information security officer. “This means that anyone gaining access to the hashed passwords does not have the actual passwords.”

    The company said the security researcher who found the user database reported it on Monday, June 4. The file contained the email addresses and hashed passwords of 92,283,889 users who created accounts at MyHeritage up to and including Oct. 26, 2017, which MyHeritage says was “the date of the breach.”

    MyHeritage added that it is expediting work on an upcoming two-factor authentication option that the company plans to make available to all MyHeritage users soon.

    “This will allow users interested in taking advantage of it, to authenticate themselves using a mobile device in addition to a password, which will further harden their MyHeritage accounts against illegitimate access,” the blog post concludes.

    MyHeritage has not yet responded to requests for comment and clarification on several points. I will update this post if that changes.

    ANALYSIS

    MyHeritage’s repeated assurances that nothing related to user DNA ancestry tests and genealogy data was impacted by this incident is are not reassuring. Much depends on the strength of the hashing routine used to obfuscate user passwords.

    Thieves can use open-source tools to crack large numbers of passwords that are scrambled by weaker hashing algorithms (MD5 and SHA-1, e.g.) with very little effort. Passwords jumbled by more advanced hashing methods — such as Bcrypt — are typically far more difficult to crack, but I would expect any breach victim who was using Bcrypt to disclose this and point to it as a mitigating factor in a cybersecurity incident.

    In its blog post, MyHeritage says it enabled a unique “hash key” for each user password. It seems likely the company is talking about adding random “salt” to each password, which can be a very effective method for blunting large-scale password cracking attacks (if implemented properly).

    If indeed the MyHeritage user database was taken and stored by a malicious hacker (as opposed to inadvertently exposed by an employee), there is a good chance that the attackers will be trying to crack all user passwords. And if any of those passwords are crackable, the attackers will then of course get access to the more personal data on those users.

    In light of this and the sensitivity of the data involved, it would seem prudent for MyHeritage to simply expire all existing passwords and force a password reset for all of users, instead of relying on them to do it themselves at some point (hopefully, before any attackers might figure out how to crack the user password hashes).

    Finally, it’s astounding that 92 million+ users thought it was okay to protect such sensitive data with just a username and password. And that MyHeritage is only now getting around developing two-factor solutions.

    It’s now 2018, and two-factor authentication is not a new security technology by any stretch. A word of advice: If a Web site you trust with sensitive personal or financial information doesn’t offer some form of multi-factor authentication, it’s time to shop around.

    Check out twofactorauth.org, and compare how your bank, email, Web/cloud hosting or domain name provider stacks up against the competition. If you find a competitor with better security, consider moving your data and business there.

    Every company (including MyHeritage) likes to say that “your privacy and the security of your data are our highest priority.” Maybe it’s time we stopped patronizing companies that don’t outwardly demonstrate that priority.

    For more on MyHeritage, check out this March 2018 story in The Atlantic about how the company recently mapped out a 13-million person family tree.

    https://krebsonsecurity.com/2018/06/researcher-finds-credentials-for-92-million-users-of-dna-testing-firm-myheritage/





Tmux Commands

screen and tmux

A comparison of the features (or more-so just a table of notes for accessing some of those features) for GNU screen and BSD-licensed tmux.

The formatting here is simple enough to understand (I would hope). ^ means ctrl+, so ^x is ctrl+x. M- means meta (generally left-alt or escape)+, so M-x is left-alt+x

It should be noted that this is no where near a full feature-set of either group. This - being a cheat-sheet - is just to point out the most very basic features to get you on the road.

Trust the developers and manpage writers more than me. This document is originally from 2009 when tmux was still new - since then both of these programs have had many updates and features added (not all of which have been dutifully noted here).

Action tmux screen
start a new session tmux OR
tmux new OR
tmux new-session
screen
re-attach a detached session tmux attach OR
tmux attach-session
screen-r
re-attach an attached session (detaching it from elsewhere) tmux attach -d OR
tmux attach-session -d
screen -dr
re-attach an attached session (keeping it attached elsewhere) tmux attach OR
tmux attach-session
screen -x
detach from currently attached session ^b d OR
^b :detach
^a ^d OR
^a :detach
rename-window to newname ^b , <newname> OR
^b :rename-window <newn>
^a A <newname>
list windows ^b w ^a w
list windows in chooseable menu ^a "
go to window # ^b # ^a #
go to last-active window ^b l ^a ^a
go to next window ^b n ^a n
go to previous window ^b p ^a p
see keybindings ^b ? ^a ?
list sessions ^b s OR
tmux ls OR
tmux list-sessions
screen -ls
toggle visual bell ^a ^g
create another window ^b c ^a c
exit current shell/window ^d ^d
split window/pane horizontally ^b " ^a S
split window/pane vertically ^b % ^a |
switch to other pane ^b o ^a <tab>
kill the current pane ^b x OR (logout/^D)
collapse the current pane/split (but leave processes running) ^a X
cycle location of panes ^b ^o
swap current pane with previous ^b {
swap current pane with next ^b }
show time ^b t
show numeric values of panes ^b q
toggle zoom-state of current pane (maximize/return current pane) ^b z
break the current pane out of its window (to form new window) ^b !
re-arrange current panels within same window (different layouts) ^b [space]
Kill the current window (and all panes within) ^b killw [target-window]
  • Make ISO from DVD

    In this case I had an OS install disk which was required to be on a virtual node with no optical drive, so I needed to transfer an image to the server to create a VM

    Find out which device the DVD is:

    lsblk

    Output:

    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 464.8G 0 part ├─centos-root 253:0 0 50G 0 lvm / ├─centos-swap 253:1 0 11.8G 0 lvm [SWAP] └─centos-home 253:2 0 403G 0 lvm /home sdb 8:16 1 14.5G 0 disk /mnt sr0 11:0 1 4.1G 0 rom /run/media/rick/CCSA_X64FRE_EN-US_DV5

    Therefore /dev/sr0 is the location , or disk to be made into an ISO

    I prefer simplicity, and sometimes deal with the fallout after the fact, however Ive repeated this countless times with success.

    dd if=/dev/sr0 of=win10.iso

    Where if=Input file and of=output file

    I chill out and do something else while the image is being copied/created, and the final output:

    8555456+0 records in 8555456+0 records out 4380393472 bytes (4.4 GB) copied, 331.937 s, 13.2 MB/s

    Fin!

    read more
  • Recreate postrgresql database template encode to ASCII

    UPDATE pg_database SET datistemplate = FALSE WHERE datname = 'template1';

    Now we can drop it:

    DROP DATABASE template1;

    Create database from template0, with a new default encoding:

    CREATE DATABASE template1 WITH TEMPLATE = template0 ENCODING = 'UNICODE'; UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template1'; \c template1 VACUUM FREEZE;

    read more
});