Идентификатор устройства для 2х факторной аутентификации

в бизнес приложениях MD5/SHA1/SHA2(IMEI) как правило

Какое imei у браузера?

А разве есть варианты кроме куки с хешем сессии и привязки к конкретному IP или целой подсети?

Ну куку по идее можно украсть, а смена IP не приводит у контакта к тому что опять требуется вводить смс. А если без особых проблем можно подделать этот фингер принт то смысл в 2х факторной аутентификации теряется

Я же сказал «или целой подсети». При реконнекте IP будет всё равно из той же подсети. А вот если IP улетит в другой город или даже страну, то двухфакторная авторизация как раз таки должна слететь. Иначе она реально только от куки зависит. Что всё равно немного повышает безопасность - надо стырить именно куку, а не пароль.

у контакта не слетает на сколько я помню:)

Значит это только защита от перебора пароля и от подсмотренного пароля. Защиты от кражи кук нету. Кроме того, что есть кнопочка «завершить все сессии», которая приведёт к необходимости перелогинится (а значит потребуется пароль и вводить код из СМС).

двухфакторная авторизация != авторизация с двумя переменными. Проверок может быть куда больше, просто они включают проверки двух из трех типов - «что ты знаешь», «чем ты владеешь» и «что ты есть».

Многие приложения контролируют соответствие сессии текущего пользователя с определенными параметрами. Как правильно сказали выше, это и подсети (и конкретные IP-адреса) и даже MAC-адреса устройств. Есть специализированные параметры хранящиеся на физическом уровне, о которых вы не знаете и не должны знать. К сожалению, все данные легко подменяются. Ну и MitM-атаки еще никто не отменял, благо дураков навалом. Доверять фактору типа «I have» лучше со слов самого пользователя, это снижаем уровень ответственности владельца приложения. Т.е. совмещая два фактора «I know» + «I have». Это значит вы сами должны определять доверенное устройство (что зачастую мы и видим в таких приложениях как AppleID, например). Теперь о возможной подмене данных. Во-первых, согласно более свежей спецификации TOTP — к вам добавляется новый параметр — время. Если заглянуть в спецификацию, можно увидеть следующее

We RECOMMEND a default time-step size of 30 seconds. This default value of 30 seconds is selected as a balance between security and usability.

И есть сами пароли, которые зачастую имеют размер 6-8 (или вид пин-кода) и состоят из цифр. Но, например, тот же яндекс с этим не согласен, и генерирует пароли по особому, где даже просчитывает алгоритмы перебора в пределах рекомендуемых 30 секунд. Ну я думаю не секрет что у яндекса давно уже наблюдается острый галлюцинаторный психоз.
А теперь самое главное:
Допустим злоумышленник перехватил куки файлы в которых хранится идентификатор сессии. Скажем, злоумышленник достаточно крут, и владеет всей необходимой информацией о жертве в довесок (будь то IP/MAC/все что угодно), но главное чего нет у злоумышленника — алгоритма проверки легитимности первого фактора. Потому что он находится на стороне сервера. Да, этот алгоритм базируется на данных клиента, но в каком порядке/какие данные для этого используются/приправы для вкуса — этим злоумышленник не владеет и по определению владеть не может (ну если все же владеет, дальнейшие рассуждения на тему подмены не имеют смысла). Пусть даже он в состоянии пройти первый шаг. Не владея доверенным устройством, он попадает на второй шаг, т.к. проверка легитимности обнаружит подмену (еще раз, алгоритм легитимности знать не должен ни пользователь, ни злоумышленник, помимо всяких IP/MAC-ов там может быть все что угодно, вы не можете и не должны этого знать). Получается, даже используя MitM-атаку у злоумышленника есть на все про все 30 секунд (если следовать спецификации 6238). Да, такая атака возможна, но маловероятна.
Ну и прогресс давно уже шагнул вперед. Возьмем то же яблочно. Биометрические данные на корпоративном уровне используются давно и достаточно активно. Причем не только пресловутый отпечаток, но и различные параметры типа рисунков вен, геометрий кистей/лиц/тела, различных размеров, модификаций голоса, узоров радужной оболочки и сетчатки и т.д. и т.п.
Резюмирую и отвечу на вопрос:

Подскажите, как контакт, гугл и прочие формируют Id устройства для добавления в доверенные для 2х факторной аутентификации?

Никто вам этого не подскажет. Т.к. вы не должны это знать. Если же вы хотите сами написать алгоритм проверки легитимности устройства — добро пожаловать в Google.

...вам необходим идентификатор браузера? - man user agent string

нужен уникальный? это сессия, остальное ненадежно и невозможно, даже ipv6 не справится

Если нужен идентификатор профиля на примере синхронизации лисы, очевидно он генерится. Что-то там pair device ...