HACKLOG 2×15 – Attacchi all’Autenticazione Web (Sicurezza sulle Password)


The concept of authentication revolves around
to common elements in which it is easy to come across. Let’s see them together:
Username and Password: the form of authentication most popular on the Web, which consists of one
combination of Username and Password. This is entirely entrusted to the Web Server
or to the Web Application. Authentication services: authentication
is managed by third parties. The user logs in to his account
external and, through programming APIs, the web application is able to recognize
the user and then to authenticate it. Some services can offer this
tool are: Google, Microsoft, Yahoo, Github, Facebook etc …
Two-factor authentication: authentication can be done via username / password
through third parties: through various techniques storage (for example via cookies
or user sessions) the server trusts that browser or program (or software) that
has performed a double authentication through the generation of external in-app codes (such as
Authy or Google Authenticator) or with systems alternative communications, including SMS
or Email. It is therefore important to bear in mind that, in
based on the type of login you will be presenting in front, it will be necessary to have all the
elements that allow you to try your own forcing. In addition, further variables are added to these
which must be borne in mind, namely: Blocking attempts: Perform repeated
attempts to attack an account may cause temporary blocking of the
same. Times on attempts: Some systems have
a minimum waiting time between attempts login and another, to avoid attacks
bruteforcing automatics. What are the methods used to ask
these passwords? Obviously through the logins (more precisely
the Login Forms). There are mainly two types: authentication
HTTP and Web App authentication. The login based on the HTTP protocol comes
shown as a browser pop-up: this one type of login is in fact integrated into the
web browser and requires little knowledge to be used effectively on a portal. Does not require the design of cookies, id
session or login pages: more simply, does not require any programming knowledge. All the authentication process comes
managed by the Web Server. Authentication in its basic form
HTTP is defined precisely HTTP Basic Authentication: more simply it means that, given one
list of credentials present in a file (encoded in base64), the user who wants to perform
the login will have to enter the data that match within this file. Each Web Server manages an authentication
HTTP according to your needs: taking for example an Apache-type Web Server (the
more common and popular) the login structure HTTP Basic Authentication is made up of two
file: .htpasswd: the files are saved in this file
credentials .htaccess: in this file there are the directives
that communicate to the client how it comes established authentication and what is the file
(.htpasswd) from which to draw information A decidedly more difficult approach to
realize and that requires programming skills is given by the design of a system
Web App based authentication. To be clear, let’s take a classic WordPress:
the login is managed by the Web App that will be connected to a database and from which it will draw
the necessary information (such as credentials). The web app will always take care of reading
the data entered in the login form, compare them with what is present and, if everything goes by
the right way, give yourself the chance to access the functions reserved for users only
sign in. To avoid “forgetting” which user you
is usually a session will be created or more commonly a cookie. The Default Password, or password
standard provided by a service provider or product, it is certainly the least popular
in the “classic” Web environment, as this is provided when a system is started
not working yet. For this kind of password it is recommended
use of specific databases: one that we recommend it is surely that of CIRT.net which is a lot
well supplied from this point of view. We define all those passwords as “Pigre”
created by sysadmin or device managers and computer networks created using simple
elements obtained instead from OSINT: in this category we find numbers and consequential codes,
birth dates, mobile numbers, codes tax or VAT number, company name or
of family members and so on. Some Web Apps allow users to restore
the password following different procedures, between these are:
Recovery through the answer to a question safety;
Recovery through a recovery code sent by e-mail;
Recovery through a recovery code via SMS;
Recovery through backup keys; Other internal recovery systems (modification
of an administrator, recovery procedures internal, forms-based procedures,
recognition recovery procedures through documents etc …). Of these methods, only the first does not offer
adequate security for the user: this is caused by the fact that often the information
compiled during registration (sui questions and answers proposed) refer to
to information recoverable through OSINT or Pigre Password. In particular, Social Networking tools
(see Facebook in the first place) allow to know easily readable information
from the questions that are trivially proposed to the user (The name of your pet,
the way you were born, the name of your best friend and so on).

3 thoughts on “HACKLOG 2×15 – Attacchi all’Autenticazione Web (Sicurezza sulle Password)

  1. Il terzo libro potresti chiamarlo ex0loitation, haibfatto anonimato, web hacking manca solo exploitation
    Solo un idea

Leave a Reply

Your email address will not be published. Required fields are marked *