Moscow Polytechnic University has not heard about confidentiality

Why is it not worth submitting documents through the Moscow Poly website, what is the threat to the applicant’s personal data and what can data leakage lead to? All this is in this article.

Disclaimer: I am not a qualified computer or information security professional. The purpose of the article is to acquaint the reader with the existing “defect” of the Moscow Polytechnic University website and give reason to think about other ways of submitting documents if the reader is especially sensitive to the placement of personal data on the Internet. Enjoy reading!

How the article was born

In connection with the update of the admission rules, on April 1, 2023, the work of the admission committee of the Moscow Polytechnic University (aka MPU, aka Polytech) began. Whether it’s good or bad is up to everyone to decide, however, I believe that if you submit documents earlier, this will allow you to get rid of unnecessary worries during the general wave of filing documents. In such periods, something else can fly out of your head.

I chose the Polytechnic University as one of the universities for admission to the master’s program after graduating from the “IT” specialty of one of the best regional universities. And MPU just has a good hostel, as well as a couple of interesting programs for me. Therefore, without thinking twice, I registered on the Polytechnic website in order to submit documents online without spending money on a flight to Moscow or sending by mail.

Note: initially, of course, I wanted to apply through the State Services – after all, they have more confidence in terms of the safety of personal data. But there, the admission campaign begins only in June, so there was only one option – registering for a personal account on the university website.

What does the Polytechnic University know about the applicant?

For registration, a full name, date of birth, mail, password and, – attention – passport data, are required as a standard. I don’t know why they are needed at this stage. So that bots and fakes are not registered?..

Already a “bell”, but God bless him, we are registering.

After all, this is the site of a well-known metropolitan university, my personal data will certainly be safe.

🙂

After registration, the site immediately offered to fill out a questionnaire, in which my passport data entered at the previous stage were kindly and automatically entered.

The questionnaire also requires a standard set of data about yourself for admission: citizenship, cell phone, registration, address of residence, scans of SNILS and passports (including page 19), etc.

The result is a good set of personal data of the applicant:

FULL NAME;

Date and place of birth;

Floor;

Email (aka login) and password;

Mobile number (or even two, including a spare);

Passport data (first page, page with registration and page 19, which contains data on previous and foreign passports) and its scans;

SNILS document number and its scan.

All this is stored on the servers of the MPU. And the password in this list is no coincidence.

The Polytechnic University knows the username and password of the applicant.

He himself makes this clear by sending, after registration, a letter with a login and a password to enter to the specified mail.

Let’s just pretend that we don’t see typos in the automatic mailing.

Why storing user passwords is bad?

In the letter above, the Polytechnic University sent me a login and password. In order to insert this data into the letter, the system must take it from somewhere. Systems take data from a database, but before that, the data must get into this database. Obviously, the login and password were written to the database as plain text after registration – after sending the form with the login, password, full name, etc. to the server.

Conclusion: Logins and passwords of applicants (and maybe not only) are stored by the Polytechnic University in the database “as is”. And there are no guarantees that after sending this letter to the registrant, this data disappears from the database.

The problem is that, like (almost) any database, the Polytech database is not 100% leak-proof. As well as the entire system is not 100% protected from hacking. Accordingly, the data from the database can fall into the hands of intruders or even in the public domain. In this case, by stealing only usernames and passwords, attackers can gain access to the entire list of personal data specified in the previous section of the article. And this is not good, I think, and so it is clear.

How could the problem be solved

— But in order to authorize a user, the system must know his login and password! After all, you need to know the correct password, whether the user entered it or not, an indifferent reader will object.
“True, but only partly,” the author answers.

Possible Solution – hashing. To be precise, authentication with a hash.

A small educational program: hashing is the process of converting any data into a fixed-length string consisting of letters and numbers. This process is carried out with the help of the so-called. cryptographic hash functions, for example, SHA-1, RIPEMD-160, MD5, etc.
For those interested, I will leave a link to a good an article in which the author describes their “nature” in more detail.

If we talk about the essence of this article, then hashing refers to those types of mathematical operations that are easily calculated “in one direction”, but rather difficult to reverse.

Example: an elementary school student will be able to multiply two prime numbers, for example,
709 * 941 = 667169. But to perform the reverse operation – to find out the factors from the product – is already a non-trivial task.
Similarly with hashing, you can hash the word “amogus” using a function such as SHA-1, getting the string “f49440bf4d3ce333c46b6bc86618937fe39eaa2e”. But in order to translate this string back into a word, it will take quite a lot of time and computing power.

Now consider an example regarding authorization:

Let’s say
my login – user1,
and my password is qwerty123 (never use such a password).
I came up with them when registering on some site.

At first glance, the system can simply take them in this form and write them to the database either as a “login-password” pair, or in a conditional table with the “Login” and “Password” columns, or in some other way. And then, when the user tries to enter the site, compare what he entered in the “Login” and “Password” fields with what is stored in the database, respectively.

This would be fine if the previously described security and leak problem did not arise.

The problem is solved by hashing (at least) the password.

The entered password is hashed when registering an account, and this very hash is written to the database on the server – a character string generated by the hash function.
In my case:

qwerty123 —> 5cec175b165e3d5e62c9e13ce848ef6feac81bff.

Thus, instead of the pair “login-password” (user1 — qwerty123) the database stores a pair of “login-hash” (user1 — 5cec175b165e3d5e62c9e13ce848ef6feac81bff), which is much less interesting for data thieves.

For this reason, well-known companies such as Google, Apple, Microsoft, etc. do not send a password to the mail if you click “Forgot Password”. They ask you to come up with a new password because they are old they just don’t know. They have a hash based on the password, but no password itself.

In this case, the authorization procedure proceeds in a similar way: after the user presses the “Login” button, the password is first run through the same hashing algorithm that was used during registration, and only then sent to the server to check whether the login is correct and the hash is correct.
(It is also possible to hash the password already on the server, this will increase the performance of the site on the client, but from a security point of view it is still not recommended.)

If the login and hash values match what was written to the database during registration – “welcome to the site, user1“.
If not, then “invalid username or password.”

This solution is much safer in terms of potential leaks. At a minimum, this will complicate access to data by ill-wishers. However, we all understand that nothing is impossible 🙂

Be careful, dear readers.
If a company emails you with your login details, think ten times before posting any personal information on their website.