38

I'm not from Information Security or any IT related area. But I want to know if there is any security reason for my digital bank to demand my phone to be on "Automatic Date & Time"?

For example, if I'm abroad, I cannot transfer some money to a friend, because a dialog box says that my date and time is incorrect.

Is that a badly programmed software or does it have a purpose?

mentallurg
  • 8,536
  • 4
  • 26
  • 41
RA828
  • 493
  • 4
  • 7
  • 6
    The title and body of your question don't match. Do you need to have "Automatic Date & Time" on, or do the date and time just need to be correct? – Joseph Sible-Reinstate Monica Jul 11 '20 at 03:44
  • 4
    I once spent an hour on a help desk call because the old phone I dedicated to 2FA apps forgot its WIFI settings and its clock had gotten out of sync. At the 45 minute mark I realized what had happened, reset the time, and everything worked. Felt rather silly. – zero298 Jul 11 '20 at 19:07
  • 61
    When you go abroad, don’t change the clock. Change the time zone. Changing the time zone doesn’t change the time, it only changes what is displayed. Changing the clock messes things up. – gnasher729 Jul 11 '20 at 22:21
  • 4
    @zero298 don't feel silly - the bank's helpdesk didn't figure it either. – Criggie Jul 12 '20 at 01:01
  • 3
    TOTP tokens immediately come to mind. – Polygnome Jul 12 '20 at 09:30

8 Answers8

51

One of the reasons can be the usage of the digital signature. If the time on your phone differs essentially from the actual current time, this may cause your phone to reject signatures done by the bank server, or your bank to reject signatures done by your phone.

Why is "Automatic Date & Time" important? Of course, the internal time representation on the phone (milliseconds from 01.01.1970 till now) does not depend on the time zone. But it depends on what you do with this. Suppose you are in the time zone ACT = GMT-5. Suppose your local time is 4:00 ACT, which is 9:00 GMT. Now suppose you disabled "Automatic Date & Time" and set the current time zone explicitly to GMT. Your phone shows immediately not 4:00, but 9:00. The internal time representation remains still unchanged, only GUI representation changed.

But now you see, that 9:00 on your phone differs from the time on your friend's phone. So, you manually set time to 4:00. Now both your phone and your friend's phones show 4:00. But your friend uses ACT = GMT-5, where as you use GMT. Thus, the internal representation of the time on your phone is 5 hours behind the real time.

In such case, even if the bank allows tolerance +- 1 minute, this will be not sufficient. Any operations where time comparison is involved will fail.

mentallurg
  • 8,536
  • 4
  • 26
  • 41
  • 6
    @user1067003 the essential part of this answer is that the actual time was changed to compensate for an incorrect timezone. The timezone itself would be irrelevant, if not for that. – Jacob Raihle Jul 13 '20 at 12:28
  • I think the underlying question is whether depending on a timestamp set by the client is sensible, given that a malicious client could choose any time setting when talking to the bank. It sounds like the purpose is to defend against a malicious client replaying a request from an honest client, assuming the honest client and bank are synchronized? – stewbasic Jul 14 '20 at 01:13
  • @stewbasic: We don't have source code of this app. So we cannot say what the actual reasons are. Protection against replay attacks can be one of the reasons. – mentallurg Jul 14 '20 at 06:14
19

There are security reasons why your bank may expect your mobile to have automatic date and time enabled. This will include protection against replay attack, where each request includes a timestamp, which is validated on server-side.

Having said that, time zones should have nothing to do with it. If you go abroad and can't use your bank mobile app, I'd suggest you to call your bank and make a complaint. To me it sounds like the original mobile app requirements might have been correct, but the implementation ended up with a defect.

automatictester
  • 652
  • 3
  • 11
  • 24
    More likely user error, changing the time instead of the time zone. Setting the time automatically avoids that kind of user error. – gnasher729 Jul 11 '20 at 22:24
18

In addition to Tim's answer, I would add that it also has to do with how SSL Certificates are verified.

If you log onto your computer instead of your phone, and change the date and time on your computer so that it doesn't match your current location time zone and time, you will run into all kinds of errors when you simply browse the internet. That's because the SSL certificates used to verify websites are not permanent, and there is a time comparison that happens within your internet browser (firefox, chrome etc...) to make sure that SSL Certificate the website uses is CURRENTLY valid.

If the system doesn't know your accurate current time, it can't verify the current validity of the security certificates used by the sites you are trying access. The same would be true for accessing a banking app on your phone, because the app connects to a server that uses certificates to verify it's authenticity.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Sean Larabee
  • 309
  • 1
  • 3
  • 7
    SSL Certificates are renewed every few months, though, at most. A few hours difference is unlikely to cause a certificate to seem ot have expired. – user253751 Jul 12 '20 at 14:59
  • 3
    https://security.stackexchange.com/a/72871/ – 9Rune5 Jul 12 '20 at 16:34
  • 5
    I'm having trouble generating any kind of error on any browser in any configuration after changing the time and time zone. This looks like an edge problem on the day that a particular certificate expires and not a common issue. Can you replicate or generate this problem? – schroeder Jul 13 '20 at 10:08
  • My company's servers are set up to not accept https connections if server and client are more than five minutes apart (may be one minute). Obviously http won't be accepted at all. – gnasher729 Jul 13 '20 at 19:09
  • I'm sorry to say, none of the Answers above seems to be realistic. Look at gnasher729's Comment and consider whether it follows any real logic? How is it not obvious that either the time matches perfectly, or the whole thing is arbitrary… or, more likely, both? – Robbie Goodwin Jul 13 '20 at 21:49
  • Times never match exactly. You don’t want to demand a match that fails in ordinary use. What you want is a match that is close enough that an attacker doesn’t have time for a replay attack. – gnasher729 Jul 14 '20 at 16:08
12

There are numerous security algorithms that limit the window of time in which something is valid.

Regardless of the security mechanism, the concept is that a code is generated that can be used to authenticate or prove an identity. But given time, any code could be broken. So the idea is to limit the amount of time possible to break the code by only allowing the code to be valid for a very short amount of time -- after which that code is no longer valid and a new code would be required. Sometimes it's hours ... sometimes it's minutes or even a few seconds. This means the clocks on both sides need to be reasonably synchronized.

With that aside... time-zones usually don't matter. Computers are typically set to UTC (Universal Time) and the time-zone is simply an offset in some number of hours (and occasionally half-hours) to change the time displayed relative to Universal Time. But the algorithms are typically based on Universal Time -- not the local time-zone.

Tim Campbell
  • 241
  • 1
  • 4
  • 5
    Nepal, Chatham Islands and Eucla are offset with a number of hours and 45 minutes offset from UTC, according to https://www.worldtimeserver.com/learn/unusual-time-zones/. Not that it adds any meaningful information to the answer, just some interesting information about time zones. – Polygorial Jul 11 '20 at 13:46
8

Your bank might be using TOTP one-time-passwords for secure authentications (often used in mobile token generator). So, secure code required to login generated from your PIN will be completely different now and in 5 minutes.

The security idea is that if someone can get you to generate one-time-password while they can observe it, but stop you from using it, they won't have unlimited time to abuse the one time code, but only a very short one.

As for not working without "Automatic Date & Time" in another country, I'd guess it is related to timezones.

Matija Nalis
  • 2,115
  • 12
  • 18
7

Some authentication protocols such as Kerberos require both parties (your phone and the bank's server) to be synced to within a few minutes of each other. Manually setting the time on your phone may not be accurate enough for your bank's implementation of Kerberos, thus the bank has chosen to check if your phone has automatic time updates enabled, and refuses to work if it is correct.

There are extensions to Kerberos to allow the server to send its current time to the client - the client will use this time instead of its own, but your bank may have chosen not to implement this

CSM
  • 221
  • 1
  • 3
2

Legitimate reason:

Digital signature and authentication schemes generally depend on proper time setting. The software may use some security tokens that are only few minutes (as in Kerberos) or even only few seconds valid. There are a good reasons for that (as in preventing token reuse by malicious parties)

Less-legitimate reasons: As the above, but software getting UTC and time zones calculations wrong. Well, it happens and such software only works in its own timezone (and sometimes even break there because of DST changes or something else).

A misguided approach to geo-limits: the software intentionally not working in different time zone because its developers think that only thieves and no legitimate user will use it abroad.

A wrong approach to date boundaries: your transaction request may appear to be a day in the future or in the past. The underlying bank transaction system may detect a fraud attempt.

etc, etc...

fraxinus
  • 3,425
  • 5
  • 20
0

Suppose that on June 1, 2020 there was a data breach that leaked the private key for yourbank.example.com's certificate, and on June 2, 2020, the certificate authority that issued your bank's certificate included a revocation for that certificate. Anyone who requests and receives the current status of that certificate between June 2, 2020 and the time the certificate would have expired would receive a notification that the old certificate was no longer valid.

If, however, the computer's clock were set to August 1, 2019, an attacker who knew this, and who had control over the computer's Internet connection could direct connection attempts to a variety of phony servers, including one which would claim that the date was August 1, 2019, and one which would claim that the yourbank.example.com's certificate had not been revoked (as of August 1, 2019, it would not have been). While attackers' ability to exploit this might be limited for computer-clock values that are in the recent past, the further off the clock is allowed to be, the greater the possibilities for mischief.

Such issues create something of a catch-22 for systems that will only be connected to the Internet very rarely (e.g. once every few years), and may not know the date when they do connect. Without a means of knowing whether a time server's certificate is still valid, one would have no way of knowing whether the reported time from what seems to be a time server might be maliciously manipulated. Requiring that users set the time and date may be crude, but if the user is paying attention, it should protect against that sort of manipulation.

supercat
  • 2,029
  • 10
  • 10