Blog

Basic problem related to logging in

Basic problems related to logging in

Logging consists of several stages, but to what extent are we able to really use them well? How much do we believe in logging in without evidence and what are we really able to solve?

Identification, authentication and authorization

Authentication is the basis of trust, because the assignment of rights presupposes adequate authentication of users. Without this authentication, the assignment of rights makes no sense, it would provide authorization beyond trust. And if we don't trust someone, why should we give them any information? For this reason, it is necessary to understand how authentication works. Therefore, identification is at the beginning of authentication.

Identification and its explanation

Identification describes the process by which the applicant for a login declares himself to be a person. In reality, the closest thing to this process is the form of a performance. Thus, a person announces that he or she has a name (he or she identifies himself or herself). Now he or she still has to prove it, this is what authentication does.

Authentication and its explanation

Authentication is significantly more complicated. The applicant is authenticated by the system to which he or she is logging. This can have different ways and has a lot of limitations, which this article will address. The authentication is usually based on some non-public knowledge, properties or possession of the device. In reality, it is possible to imagine authentication by a password, i.e. a shared secret, the same way as when classmates meet years later. They do not have to know each other, but they have shared memories of school years. These can work the same way as a password. In everyday life, the memory of an encounter can also be reminded by a voice and other "biometric data", but in the case of computers, their informational value is low. Only by proving the authenticity of the given identity can we solve the assignment of corresponding rights.

Authorization and its explanation

Authorization is the last part of the triad. It ensures the assignment of rights to the applicant, who correctly proved himself or herself, i.e. proved to the system the authenticity of the information provided. Subsequently, the system grants the applicant rights to access the information offered. Transferred to a life example, you will discuss stories from school and news from your life with a former classmate or classmate. But you will probably not treat a random acquaintance in this way.
Currently, the effort is to ensure the minimum necessary permissions when assigning rights, the so-called LUA (Least User Access or Least-privileged User Account). The so-called RBA (Role Based Access) is usually used for the assignment of rights, as well as other methods (MAC, DAC ...). But about these at some other time, as well as problems with managing access to information.

Problems of authentication against the service

So far, it all seems reasonable, but is it that simple? If we look at the authentication itself more closely, problems begin to appear. As stated, the applicant (user) is authenticated against the server. But against which server? Is this server authenticated? It is not always so. At present, there are nearly two hundred authentication mechanisms available, some of these mechanisms are supported by dozens of algorithms. A large part of them are more than a few decades old. They were certainly not created on the basis of criteria corresponding to current security requirements. Why is this such a problem? In short, not every mechanism allows to verify to whom a user is authenticated. And because it is sometimes a technological challenge, the design of the mechanisms quietly assumes that this control will be provided by the users. The consequences of such a procedure may be, for example, forged login services, which in turn allow the misuse of accounts. Therefore, it is an effort to solve these problems, as access is offered by the so-called MFA (Multi Factor Authentication).

Why MFA is interesting

MFA is the use of principles, when the user knows a secret (password, key), but at the same time it is possible to ensure its authentication by means of something else that they own, who they are or even other secrets. For example, a device that provides them with data important for login, such as a mobile phone or e-mail account, to which the authentication message arrives. The weakness of these procedures is a maximum effort to simplify and ensure user comfort. This can only be done to a certain extent. Therefore, it is difficult for the user to determine whether there was accidental multiple login or forgery of the target server. Similarly, it is difficult to detect a potential attacker intercepting communication with the device, or possibly directly attacking the device and controlling it. Such efforts present a large number of technical challenges. Therefore, the aim is to use as one of the methods of protection the extension of MFA properties by the method of authentication through another channel (OOB - Out Of Band).

Why use OOB

This is the use of MFA, where each factor (each separate property) is authenticated by another channel. This limits the possibility of attacking the platform or channel, because without additional information provided by another channel, login is not possible. But as all systems gradually adapt to user comfort and safety comes second, the "comfort vector" becomes the biggest weakness. This risk is currently found in a large number of mobile applications that provide user identification and authentication in one place for convenience. As a rule, one channel is used because comfort has the highest priority at the expense of security. The control of such a device can then have fatal consequences on user privacy.

Biometric authentication

Apparently, everyone wonders why it is difficult to solve authentication when it is possible to provide authentication by fingerprint, photograph, voice or other measurable characteristics of the person. This comment is very difficult to answer. The reason for the difficulty of answering this is actually just to measure the capabilities of biometric sensors. Each such sensor has a certain reliability, called False Positive Rate (FPR, usually 0.01%) and False Negative Rate (FNR, usually 0.1%). These values determine the error rate of a device where the false positive frequency specifies how likely the accidental user will be falsely accepted in the system. By contrast, the false negative frequency determines the probability of rejecting the correct user. Moreover, you can never be sure if you are not in control of such a device.
For a closer explanation of the terms FPR and FNR. An example of a false positive confirmation is when a doctor identifies a young man as pregnant on the basis of morning sickness. Conversely, a false negative confirmation is in the case of declaring a woman in late pregnancy to be a simulant because she is missing morning sickness.
Currently, thanks to developments in security, it is possible to create universal fingerprints, false audio tracks or even universal faces. Artificial intelligence is a huge and difficult problem for biometrics. Outside of artificial intelligence, there is the development of technology, where cellphone cameras have managed to capture fingerprints on glasses, which could theoretically be used to log in. Who knows where the boundaries are, biometrics are measurable signs specific to each person. Because these are data, they are also falsifiable. Another curiosity comes from mathematics, this is a simple work with percentages. If there are approximately 8 billion people in the world, it would be necessary to use at least 4 different biometric factors to determine the corresponding person reliably enough (0.01% from 0.01% from 0.01% from 0.01%). Therefore, at present, biometrics can only be used on the basis of an appropriate risk analysis. For some situations it is sufficient, at other times it is absolutely inappropriate. However, the mentioned risks must always take into account the influence of the environment.

Station verification problems

Even if the above mentioned problems are covered, not everything is solved. Unfortunately, this analysis lacks a basic article. The user logs in from a particular machine. We verify the user and theoretically the server, but how do we verify the trustworthiness of the device? How do we determine compliance with the security policy? How do we work with an unknown device? If this problem is discussed, the device under your control can be controlled to a certain extent. Third party devices cannot. When and under what conditions can you allow logging in from such machines even with the risk of leaking login information? Or at the risk of letting an intruder into your internal network? These are matters that can no longer be solved technically and it is necessary to set the login rules appropriately. Generally, the problem mentioned is included under BYOD (Bring Your Own Device), but this is not entirely true. Sometimes it is "I used a foreign device" (IUFD), which is a completely different problem.

Problems solved by cryptography

Cryptography solves a lot of interesting problems during login. First, of course, it is necessary to ensure the protection of the transferred information and its integrity. It is necessary to ensure its authenticity and it would be nice to ensure its non-repudiation (it was really sent by this user and no one else). But there are other problems besides the above. First, the transferred login data must never be repeated and must be almost random and unpredictable. First of all, the password must not be repeated, so how do we process it to make it different every time? Is it necessary to transfer it at all, is it not possible to replace it by other ways? At the same time, it is necessary to ensure that once used login cannot be sent again, it is difficult to impossible to counterfeit it, it is not possible to "forward it", it is not possible to use the older version of the algorithm without the user's consent, obsolete or weak algorithms are not used … and all this must be accepted at the same time by the authentication of the target system, supporting technologies such as MFA, OOB and others. What can be done, none of the technologies is completely without error, and there are not many possibilities on the market.

Central Authorities

Different central authorities are an interesting approach. They have their advantages, because the authentication takes place against the authority and the aim is to ensure secure authentication mainly against it. Subsequently, the authenticated identity is provided to other systems, which can only carry out the authentication. There is only one big BUT. If such an authority is attacked, or if it is not working (signle point of failure), all the linked accounts can be abused. Trying to centralize is sensible, but not in all circumstances. Using central points is thus only relevant until they are attacked, i.e. it is a matter of trust. On the other hand, such a central point is of great importance for internal use in different organizations. Why it is difficult to delete an account from tens to hundreds of systems when it can be managed centrally. Leaving a worker thus means deleting all of their login data. It is not left anywhere like a funeral account forgotten for years, which is slowly becoming a time bomb.

Type of login

Although login is a basic method, it rarely supports so-called temporary locking (Intruder lock-out), which locks the account in case of a large number of bad logins. Except in rare cases, it does not support coercive and alarm login, when user permissions are limited, or informing the person responsible. These methods are virtually forgotten and their use is minimal. In addition to the above-mentioned methods of protection, password-less authentication is now taking the course. The name is a bit misleading, it is always necessary to use a password, whether it is a system password, to open a database, etc. But, more importantly, well-used methods not only ensure the protection of the transferred information, but also ensure its unpredictability. As a rule, a procedure known as "bilineration pairing" is now used for these purposes. Unfortunately, some password-less mechanisms use different or outdated methods that do not offer sufficient protection.

Conclusion

Login is a complicated system that we still do not have completely under-developed. Some of the methods are now obsolete, others can have serious problems. Administrators who confuse the notion of password policy and login management are also obsolete, but this can be done much better. Centralization of login in companies is practically necessary, but this is not always the case with centralization of login for personal use. It can lead to a loss of privacy and should be part of a person's decision whether or not to use it. Therefore, it is necessary to consider very carefully what we want to address and what we are protecting ourselves from.

Autor článku:

Jan Dušátko
Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.

1. Introductory Provisions

1.1. These General Terms and Conditions are, unless otherwise agreed in writing in the contract, an integral part of all contracts relating to training organised or provided by the trainer, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, with location Pod Harfou 938/58, Praha 9 (next as a „lector“).
1.2. The contracting parties in the general terms and conditions are meant to be the trainer and the ordering party, where the ordering party may also be the mediator of the contractual relationship.
1.3. Issues that are not regulated by these terms and conditions are dealt with according to the Czech Civil Code, i.e. Act No.89/2012 Coll.
1.4. All potential disputes will be resolved according to the law of the Czech Republic.

2. Creation of a contract by signing up for a course

2.1. Application means unilateral action of the client addressed to the trainer through a data box with identification euxesuf, e-mailu with address register@cryptosession.cz or register@cryptosession.info, internet pages cryptosession.cz, cryptosession.info or contact phone +420 602 427 840.
2.2. By submitting the application, the Client agrees with these General Terms and Conditions and declares that he has become acquainted with them.
2.3. The application is deemed to have been received at the time of confirmation (within 2 working days by default) by the trainer or intermediary. This confirmation is sent to the data box or to the contact e-mail.
2.4. The standard time for registration is no later than 14 working days before the educational event, unless otherwise stated. In the case of a natural non-business person, the order must be at least 28 working days before the educational event.
2.5. More than one participant can be registered for one application.
2.6. If there are more than 10 participants from one Client, it is possible to arrange for training at the place of residence of the intermediary or the Client.
2.7. Applications are received and processed in the order in which they have been received by the Provider. The Provider immediately informs the Client of all facts. These are the filling of capacity, too low number of participants, or any other serious reason, such as a lecturer's illness or force majeure. In this case, the Client will be offered a new term or participation in another educational event. In the event that the ordering party does not agree to move or participate in another educational event offered, the provider will refund the participation fee. The lack of participants is notified to the ordering party at least 14 days before the start of the planned term.
2.8. The contract between the provider and the ordering party arises by sending a confirmation from the provider to the ordering party.
2.9. The contract may be changed or cancelled only if the legal prerequisites are met and only in writing.

3. Termination of the contract by cancellation of the application

3.1. The application may be cancelled by the ordering party via e-mail or via a data mailbox.
3.2. The customer has the right to cancel his or her application for the course 14 days before the course takes place without any fees. If the period is shorter, the subsequent change takes place. In the interval of 7-13 days, an administrative fee of 10% is charged, cancellation of participation in a shorter interval than 7 days then a fee of 25%. In case of cancellation of the application or order by the customer, the possibility of the customer's participation in an alternative period without any additional fee is offered. The right to cancel the application expires with the implementation of the ordered training.
3.3. In case of cancellation of the application by the trainer, the ordering party is entitled to a full refund for the unrealized action.
3.4. The ordering party has the right to request an alternative date or an alternative training. In such case, the ordering party will be informed about all open courses. The alternative date cannot be enforced or enforced, it depends on the current availability of the course. If the alternative training is for a lower price, the ordering party will pay the difference. If the alternative training is for a lower price, the trainer will return the difference in the training prices to the ordering party.

4. Price and payment terms

4.1. By sending the application, the ordering party accepts the contract price (hereinafter referred to as the participation fee) indicated for the course.
4.2. In case of multiple participants registered with one application, a discount is possible.
4.3. The participation fee must be paid into the bank account of the company held with the company Komerční banka č. 78-7768770207/0100, IBAN:CZ5301000000787768770207, BIC:KOMBCZPPXXX. When making the payment, a variable symbol must be provided, which is indicated on the invoice sent to the client by the trainer.
4.4. The participation fee includes the provider's costs, including the training materials. The provider is a VAT payer.
4.5. The client is obliged to pay the participation fee within 14 working days of receipt of the invoice, unless otherwise stated by a separate contract.
4.6. If the person enrolled does not attend the training and no other agreement has been made, his or her absence is considered a cancellation application at an interval of less than 7 days, i.e. the trainer is entitled to a reward of 25% of the course price. The overpayment is returned within 14 days to the sender's payment account from which the funds were sent. Payment to another account number is not possible.
4.7. An invoice will be issued by the trainer no later than 5 working days from the beginning of the training, which will be sent by e-mail or data box as agreed.

5. Training conditions

5.1. The trainer is obliged to inform the client 14 days in advance of the location and time of the training, including the start and end dates of the daily programme.
5.2. If the client is not a student of the course, he is obliged to ensure the distribution of this information to the end participants. The trainer is not responsible for failure to comply with these terms and conditions.
5.2. By default, the training takes place from 9 a.m. to 5 p.m. at a predetermined location.
5.3. The trainer can be available from 8 a.m. to 9 a.m. and then from 17 a.m. to 6 p.m. for questions from the participants, according to the current terms and conditions.
5.4. At the end of the training, the certificate of absorption is handed over to the end users.
5.5. At the end of the training, the end users evaluate the trainer's approach and are asked to comment on the evaluation of his presentation, the manner of presentation and the significance of the information provided.

6. Complaints

6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.
6.2. The reasons for dissatisfaction are recorded in the minutes in two copies on the same day. One is handed over to the client and one is held by the trainer.
6.3. A statement on the complaint will be submitted by e-mail within two weeks. A solution will then be agreed within one week.
6.4. The customer's dissatisfaction may be a reason for discontinuing further cooperation, or financial compensation up to the price of the training, after deduction of costs.

7. Copyright of the provided materials

7.1. The training materials provided by the trainer in the course of the training meet the characteristics of a copyrighted work in accordance with Czech Act No 121/2000 Coll.
7.2. None of the training materials or any part thereof may be further processed, reproduced, distributed or used for further presentations or training in any way without the prior written consent of the trainer.

8. Liability

8.1. The trainer does not assume responsibility for any shortcomings in the services of any third party that he uses in the training.
8.2. The trainer does not assume responsibility for injuries, damages and losses incurred by the participants in the training events or caused by the participants. Such costs, caused by the above circumstances, shall be borne exclusively by the participant in the training event.

9. Validity of the Terms

9.1 These General Terms and Conditions shall be valid and effective from 1 October 2024.

Consent to the collection and processing of personal data

According to Regulation (EU) No 2016/679 of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation, hereinafter referred to as "the Regulation"), the processor xxx (hereinafter referred to as "the Controller") processes personal data. Individual personal data that are part of the processing during specific activities at this web presentation and in the course of trade are also broken down.
Although the collection of data is ubiquitous, the operation of this website is based on the right to privacy of each user. For this reason, the collection of information about users takes place to the extent absolutely necessary and only if the user decides to contact the operator. We consider any further collection and processing of data unethical.

Information about the records of access to the web presentation

This website does not collect any cookies. The site does not use any analytical scripts of third parties (social networks, cloud providers). For these reasons, an option is also offered for displaying the map in the form of a link, where the primary source is OpenStreet and alternatives then the frequently used Maps of Seznam, a.s., or Google Maps of Google LLC Inc. The use of any of these sources is entirely at the discretion of the users of this site. The administrator is not responsible for the collection of data carried out by these companies, does not provide them with data about users and does not cooperate on the collection of data.
Logging of access takes place only at the system level, the reason being the identification of any technical or security problems. Other reasons are overview access statistics. No specific data is collected or monitored in this area and all access records are deleted after three months.

Information about contacting the operator of the site

The form for contacting the operator of the site (administrator) contains the following personal data: name, surname, e-mail. These data are intended only for this communication, corresponding to the address of the user and are kept for the time necessary to fulfil the purpose, up to a maximum of one year, unless the user determines otherwise.

Information about the order form

In case of an interest in the order form, the form contains more data, i.e. name, surname, e-mail and contact details for the organisation. These data are intended only for this communication, corresponding to the address of the user and are kept for one year, unless the user determines otherwise. In the event that a business relationship is concluded on the basis of this order, only the information required by Czech law on the basis of business relations (company name and address, bank account number, type of course and its price) will continue to be kept by the administrator.

Information about the course completion document

Within the course, a course completion document is issued by the processor. This document contains the following data: student's name and surname, the name and date of the course completion and the employer's name. The information is subsequently used for the creation of a linear hash tree (non-modifiable record). This database contains only information about the provided names and company names, which may or may not correspond to reality and is maintained by the processor for possible re-issuance or verification of the document's issuance.

Rights of the personal data subject

The customer or visitor of this website has the possibility to request information about the processing of personal data, the right to request access to personal data, or the right to request the correction or deletion of any data held about him. In the case of deletion, this requirement cannot be fulfilled only if it is not data strictly necessary in the course of business. The customer or visitor of this website also has the right to obtain explanations regarding the processing of his personal data if he finds out or believes that the processing is carried out in violation of the protection of his private and personal life or in violation of applicable legislation, and the right to request removal of the resulting situation and to ensure the correction.
Furthermore, the customer/visitor of this website may request restriction of processing or object to the processing of personal data and has the right to withdraw his/her consent to the processing of personal data at any time in writing, without prejudice to the lawfulness of their processing prior to such withdrawal. For this purpose, the contact e-mail address support@cryptosession.cz is used.
The customer/visitor has the right to file a complaint against the processing of personal data with the supervisory authority, which is the Office for Personal Data Protection.