Today I opened a bank account to invest my savings. Here's the link to the login page: http://www1.directatrading.com/

I noticed it doesn't use Https protocol (neither is that page nor in the landing page where you can buy stocks etc). Moreover your password can be at maximum 10 characters long and there's no 2 step verification...

This is the page where they explain their security (it's Italian, maybe you could translate: https://www.directa.it/pub2/it/altreinfo/sicurezza.html).

Thanks for any input.

It's a large broker company so it seems strange to me they don't care that much about security (however I'm no expert).

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Aug 5, 2018 at 20:52

3 Answers 3


doesn't use Https protocol

The website you provided does support HTTPS, but not HSTS or HTTP to HTTPS redirect. That is why you could be directed to an unsecured HTTP site. SSL Labs analysis.

Moreover your password can be at maximum 10 characters

Oddly this is common of online banking. I have experienced a bank which defined the following rules for a password {az-AZ-09} with a character limit less or equal to 10.

there's no 2 step verification...

Despite this becoming a norm in security. Some still have configured their infrastructure with primitive security, given modern attack vectors. 2FA should be a must. Most banks will either provide a "secure key" or access to a one-time password from their mobile banking app.

My personal advice. Avoid online banking with this bank, and look for an alternative which can satisfy your security (OpSec) needs.

  • 3
    Ah, I didn't catch that they support HTTPS but don't force redirect HTTP to HTTPS. I'm so used to doing both in combination that I forgot you can leave out the last step! To be clear (and you could always mention this yourself), allowing HTTPS but not automatically redirecting HTTP is a big security hole because a malicious attacker could easily use it to redirect the user and steal credentials. Aug 3, 2018 at 18:07
  • 3
    SSL Strip: For downgrading HTTPS request to HTTP (unsecure) SSL Strip for Newbies - avicoder.me/2016/02/22/SSLstrip-for-newbies Kali Linux MITM Attack Tutorial: hacking-tutorial.com/hacking-tutorial/…
    – safesploit
    Aug 3, 2018 at 18:42
  • 3
    The restrictive password limits translate to the bank having a legacy COBOL system (virtually all banks do), using it for authentication (common), and it being sufficiently brittle that the risk of making any major changes to it is too high to be acceptable (depressingly common). Aug 3, 2018 at 20:23
  • 8
    "allowing HTTPS but not automatically redirecting HTTP is a big security hole" - No, it's virtually meaningless. If an attacker can redirect the user (to plain HTTP), he can also mitm with SSL stripping (against which the redirect does NOT protect). The only fail-safe way to force HTTPS is HSTS preloading. HSTS without preload is basically trust-on-first-use, with all the problems that includes. An HTTPS redirect protects against nothing (but is more or less necessary to make HSTS without preloading work).
    – marcelm
    Aug 3, 2018 at 20:24
  • 2
    @marcelm by itself it's not enough to make a site secure against a hostile entity manipulating traffic, it does protect against the far more common case where a user didn't explicitly specify https. For a financial institution not having HSTS is facepalm bad, even if everything else was done right; but also failing to handle the most common failure case - user error - is worthy of a second facepalm. Aug 3, 2018 at 20:30

Presuming that is the actual login page:

Yes, this is very insecure by modern standards, and even more so for anything involving actual monetary transactions.

There is always the slim possibility that the page loads on HTTP but then submits to a server protected by HTTPS. That would still be bad but would at least be "better". However, I confirmed that this doesn't happen. As I'm sure you know this would allow anyone on your local network (or anywhere between you and their server) to read your username and password.

There is also no CSRF protection on the login endpoint - this can introduce a lot of other more subtle security weaknesses (although not anywhere near as severe as failing to encrypt your login credentials).

The best-case scenario here is that the page you are on isn't supposed to be the primary login page, but you ended up there by accident and they forgot to remove it and direct people to the login page which is actually secure.

I ran the website describing their security through google translate. Obviously it won't be perfect, but it certainly gives the highlights:

  1. We've never had a breach before - nothing to worry about!
  2. We have a super secure firewall
  3. We use SSL encryption!
  4. You can change your password!
  5. You can deny access to your account from all but one device
  6. You can see when/where you last logged in
  7. You can get a text message everytime someone logs in
  8. Even if someone were to login your money would be safe because we don't allow transfers to any accounts not specified by you and indicated in your contract

I wouldn't take any of that very seriously, especially in light of their inability to provide SSL encryption on the login page, which is probably the most important page of all to secure. Given their lax practices here I would assume that they have security holes elsewhere in their system. Whether or not they have ever had a breach is something no one will ever know - what should say is:

If we've ever had a breach we at least don't know about it! We promise we're not lying!

If they really haven't ever had a breach it is probably because no one has ever bothered trying to target them, and not because of good security practices. I wouldn't even take point #8 seriously. You'd be surprised what people talk account support technicians into doing, and even if an attacker can't actively steal your money, this doesn't mean that they can't cause you severe harm if they get into your account.

  • 2
    "at least don't know about it" naturally, because they probably don't have adequate monitoring in place either...
    – msanford
    Aug 3, 2018 at 17:33
  • As other posters noted, they do have SSL encryption on the login page if you type https:// to get to the bank page. But you've got a lot of other good points.
    – Joshua
    Aug 3, 2018 at 20:50
  • @Joshua yeah, I didn't notice that myself until the other answers came in, but it was covered well enough in other answers that I figured there was no point in adding it to my answer. Aug 3, 2018 at 20:58
  • Even without social engineering #8 doesn't make much sense. If it's a brokerage account, an attacker would still be able to trade -- say, to buy some illiquid assets that the attacker's twin brother just happens to have for sale at a high asking price. Aug 4, 2018 at 19:11

Whomever designed the website appears to have a lack of security knowledge. As others have pointed out, they do support HTTPS, but at the very least you should be redirected from the HTTP to HTTPS when you go to the login site. That was standard for secure websites more than 10 years ago. It's extremely trivial to implement this, offers real protection from real attacks, and not having it is a red flag.

Even better would be supporting HSTS (also not supported), which is a way of publishing information on how the website should only be available via HTTPS. This standard is now almost 6 years old, and widely implemented. A bank not having this simple security measure is another red flag.

It should come as no surprise to you that Italian websites... aren't really the best. I've spent considerable time in Italy using Italian websites, and many are shockingly bad and about 15 years behind the times. This site is no exception.

The password length limits are sadly the norm for many banks. This is because much of the banking industry is itself far behind the times with an enormous amount of legacy systems still in place. The lack of 2-Factor authentication is also relatively common. Both these are indications the institution isn't focused on security, but it's far too common for these to be red flags.

I ran a test of their SSL configuration against SSL Labs: https://www.ssllabs.com/ssltest/analyze.html?d=www1.directatrading.com

It's actually not terrible (They get a B), which isn't a red flag, but is another indicator of not keeping up with security standards.

I wouldn't recommend using this financial institution since they seem to have a severe disregard for modern security practices going back at least 10-15 years. The visible problems are often just the tip of the iceberg.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .