Domanda:
Perché la mia banca digitale ha bisogno che la data e l'ora del mio telefono siano corrette?
RA828
2020-07-11 05:06:19 UTC
view on stackexchange narkive permalink

Non provengo dalla sicurezza delle informazioni o da alcuna area correlata all'IT. Ma voglio sapere se c'è qualche motivo di sicurezza per cui la mia banca digitale richiede che il mio telefono sia impostato su "Automatic Date & Time"?

Ad esempio, se sono all'estero, non posso trasferire del denaro ad un amico, perché una finestra di dialogo dice che la mia data e ora non sono corrette.

È un software mal programmato o ha uno scopo?

Il titolo e il corpo della tua domanda non corrispondono.È necessario attivare "Data e ora automatiche" o è necessario che la data e l'ora siano corrette?
Una volta ho trascorso un'ora in una chiamata all'help desk perché il vecchio telefono che dedicavo alle app 2FA aveva dimenticato le sue impostazioni WIFI e il suo orologio non era più sincronizzato.Al minuto 45 ho capito cosa era successo, azzerato il tempo e tutto ha funzionato.Sembrava piuttosto stupido.
Quando vai all'estero, non cambiare l'orologio.Cambia il fuso orario.La modifica del fuso orario non cambia l'ora, cambia solo ciò che viene visualizzato.Cambiare l'orologio rovina le cose.
@zero298 non si sente stupido: nemmeno l'helpdesk della banca lo ha capito.
I token TOTP vengono subito in mente.
Otto risposte:
#1
+51
mentallurg
2020-07-11 08:08:16 UTC
view on stackexchange narkive permalink

Uno dei motivi può essere l'utilizzo della firma digitale. Se l'ora sul tuo telefono differisce essenzialmente dall'ora corrente effettiva, ciò potrebbe far sì che il tuo telefono rifiuti le firme fatte dal server della banca o la tua banca rifiuti le firme fatte dal tuo telefono.

Perché è "automatico Data & Ora "importante? Ovviamente la rappresentazione dell'ora interna al telefono (millisecondi dall'01.01.1970 ad oggi) non dipende dal fuso orario. Ma dipende da cosa fai con questo. Supponiamo di essere nel fuso orario ACT = GMT-5. Supponiamo che l'ora locale sia le 4:00 ACT, ovvero le 9:00 GMT. Supponiamo ora di aver disabilitato "Automatic Date & Time" e di aver impostato esplicitamente il fuso orario corrente su GMT. Il tuo telefono mostra immediatamente non le 4:00, ma le 9:00. La rappresentazione dell'ora interna rimane ancora invariata, è cambiata solo la rappresentazione della GUI.

Ma ora vedi, che le 9:00 sul tuo telefono differiscono dall'ora sul telefono del tuo amico. Quindi, imposti manualmente l'ora alle 4:00. Ora sia il telefono che i telefoni del tuo amico mostrano le 4:00. Ma il tuo amico usa ACT = GMT-5, dove come usi GMT. Pertanto, la rappresentazione interna dell'ora sul telefono è di 5 ore indietro rispetto all'ora reale.

In tal caso, anche se la banca consente la tolleranza + - 1 minuto, questo non sarà sufficiente. Qualsiasi operazione in cui è coinvolto il confronto temporale fallirà.

@user1067003 la parte essenziale di questa risposta è che l'ora effettiva è stata modificata per compensare un fuso orario errato.Il fuso orario stesso sarebbe irrilevante, se non fosse per quello.
Penso che la domanda di fondo sia se dipendere da un timestamp impostato dal cliente sia sensato, dato che un client malintenzionato potrebbe scegliere qualsiasi impostazione dell'ora quando parla con la banca.Sembra che lo scopo sia difendersi da un client dannoso che riproduce una richiesta di un cliente onesto, supponendo che il cliente onesto e la banca siano sincronizzati?
@stewbasic: Non abbiamo il codice sorgente di questa app.Quindi non possiamo dire quali siano le ragioni effettive.La protezione contro gli attacchi replay può essere uno dei motivi.
#2
+19
automatictester
2020-07-11 13:45:23 UTC
view on stackexchange narkive permalink

Esistono motivi di sicurezza per cui la tua banca potrebbe aspettarsi che sul tuo cellulare siano abilitate data e ora automatiche. Ciò includerà la protezione contro l'attacco replay, in cui ogni richiesta include un timestamp, che viene convalidato sul lato server.

Detto questo, i fusi orari non dovrebbero avere nulla a che fare con questo. Se vai all'estero e non puoi utilizzare l'app mobile della tua banca, ti suggerisco di chiamare la tua banca e presentare un reclamo. A me sembra che i requisiti dell'app mobile originale potessero essere corretti, ma l'implementazione si è conclusa con un difetto.

Più probabile errore dell'utente, modifica dell'ora anziché del fuso orario.L'impostazione dell'ora evita automaticamente questo tipo di errore dell'utente.
#3
+18
Sean Larabee
2020-07-11 06:21:42 UTC
view on stackexchange narkive permalink

Oltre alla risposta di Tim, aggiungerei che ha anche a che fare con il modo in cui vengono verificati i certificati SSL.

Se accedi al tuo computer invece che al telefono e modifichi la data e l'ora il tuo computer in modo che non corrisponda al fuso orario e all'ora della tua posizione corrente, ti imbatterai in tutti i tipi di errori quando navighi semplicemente in Internet. Questo perché i certificati SSL utilizzati per verificare i siti Web non sono permanenti e c'è un confronto temporale che avviene all'interno del tuo browser Internet (firefox, chrome, ecc ...) per assicurarti che il certificato SSL utilizzato dal sito Web sia ATTUALMENTE valido. >

Se il sistema non conosce l'ora esatta corrente, non può verificare l'attuale validità dei certificati di sicurezza utilizzati dai siti a cui stai tentando di accedere. Lo stesso varrebbe per l'accesso a un'app bancaria sul telefono, perché l'app si connette a un server che utilizza certificati per verificarne l'autenticità.

I certificati SSL vengono rinnovati al massimo ogni pochi mesi.È improbabile che una differenza di poche ore faccia sembrare che un certificato sia scaduto.
https://security.stackexchange.com/a/72871/
Ho problemi a generare qualsiasi tipo di errore su qualsiasi browser in qualsiasi configurazione dopo aver modificato l'ora e il fuso orario.Sembra un problema limite il giorno in cui scade un determinato certificato e non un problema comune.Puoi replicare o generare questo problema?
I server della mia azienda sono impostati per non accettare connessioni https se il server e il client si trovano a più di cinque minuti di distanza (potrebbe essere un minuto).Ovviamente http non sarà affatto accettato.
Mi dispiace dirlo, nessuna delle risposte sopra sembra essere realistica. Guarda il commento di gnasher729 e valuta se segue una logica reale? Come non è ovvio che il tempo coincida perfettamente o che l'intera cosa sia arbitraria ... o, più probabilmente, entrambe le cose?
I tempi non corrispondono mai esattamente.Non vuoi richiedere una corrispondenza che fallisce nell'uso normale.Quello che vuoi è una partita che sia abbastanza vicina che un attaccante non abbia tempo per un attacco replay.
#4
+12
Tim Campbell
2020-07-11 06:01:22 UTC
view on stackexchange narkive permalink

Esistono numerosi algoritmi di sicurezza che limitano la finestra di tempo in cui qualcosa è valido.

Indipendentemente dal meccanismo di sicurezza, il concetto è che viene generato un codice che può essere utilizzato per autenticare o provare un identità. Ma dato il tempo, qualsiasi codice potrebbe essere rotto. Quindi l'idea è di limitare la quantità di tempo possibile per rompere il codice consentendo al codice di essere valido solo per un periodo di tempo molto breve, dopo di che quel codice non è più valido e sarebbe necessario un nuovo codice. A volte sono ore ... a volte sono minuti o anche pochi secondi. Ciò significa che gli orologi su entrambi i lati devono essere ragionevolmente sincronizzati.

A parte questo ... i fusi orari di solito non contano. I computer sono tipicamente impostati su UTC (Universal Time) e il fuso orario è semplicemente un offset in un certo numero di ore (e occasionalmente mezz'ora) per modificare l'ora visualizzata rispetto all'ora universale. Ma gli algoritmi sono in genere basati sull'ora universale, non sul fuso orario locale.

Secondo https://www.worldtimeserver.com/learn/unusual-time-zones/, il Nepal, le Isole Chatham e Eucla sono compensati con un numero di ore e 45 minuti di offset rispetto a UTC.Non che aggiunga informazioni significative alla risposta, solo alcune informazioni interessanti sui fusi orari.
#5
+7
Matija Nalis
2020-07-13 17:44:46 UTC
view on stackexchange narkive permalink

La tua banca potrebbe utilizzare TOTP password monouso per autenticazioni sicure (spesso utilizzate nel generatore di token mobile). Quindi, il codice di sicurezza richiesto per accedere generato dal tuo PIN sarà completamente diverso ora e in 5 minuti.

L'idea di sicurezza è che se qualcuno può farti generare una password unica mentre può osservarla , ma ti impediscono di usarlo, non avranno tempo illimitato per abusare del codice temporale unico, ma solo molto breve.

Per quanto riguarda il non lavorare senza "Data automatica & Time" in un altro paese , Immagino sia correlato ai fusi orari.

#6
+6
CSM
2020-07-12 16:05:31 UTC
view on stackexchange narkive permalink

Alcuni protocolli di autenticazione come Kerberos richiedono che entrambe le parti (il tuo telefono e il server della banca) siano sincronizzate entro pochi minuti l'una dall'altra. L'impostazione manuale dell'ora sul telefono potrebbe non essere sufficientemente precisa per l'implementazione di Kerberos da parte della banca, pertanto la banca ha scelto di controllare se il telefono ha gli aggiornamenti automatici dell'ora abilitati e si rifiuta di funzionare se è corretto.

Ci sono estensioni a Kerberos per consentire al server di inviare l'ora corrente al client: il client utilizzerà questa ora invece della propria, ma la tua banca potrebbe aver scelto di non implementarla

#7
+2
fraxinus
2020-07-13 17:52:37 UTC
view on stackexchange narkive permalink

Motivo legittimo:

La firma digitale e gli schemi di autenticazione generalmente dipendono dall'impostazione corretta dell'ora. Il software può utilizzare alcuni token di sicurezza che sono validi solo per pochi minuti (come in Kerberos) o anche solo per pochi secondi. Ci sono buone ragioni per questo (come impedire il riutilizzo dei token da parte di malintenzionati)

Motivi meno legittimi: come sopra, ma il software sbaglia i calcoli di UTC e fuso orario. Ebbene, succede e tale software funziona solo nel proprio fuso orario (e talvolta addirittura si interrompe a causa di modifiche all'ora legale o qualcos'altro).

Un approccio fuorviante ai limiti geografici: il software intenzionalmente non funziona in diversi fuso orario perché i suoi sviluppatori pensano che solo i ladri e nessun utente legittimo lo utilizzerà all'estero.

Un approccio sbagliato ai limiti di data: la tua richiesta di transazione potrebbe sembrare un giorno nel futuro o nel passato. Il sistema di transazioni bancarie sottostante potrebbe rilevare un tentativo di frode.

ecc, ecc ...

Probabilmente non sono sviluppatori ma capi dai capelli a punta.
#8
  0
supercat
2020-07-14 00:47:56 UTC
view on stackexchange narkive permalink

Supponi che il 1 ° giugno 2020 si sia verificata una violazione dei dati che ha fatto trapelare la chiave privata per il certificato di yourbank.example.com e che il 2 giugno 2020 l'autorità di certificazione che ha emesso il certificato della tua banca abbia incluso una revoca per quel certificato. Chiunque richieda e riceva lo stato corrente di quel certificato tra il 2 giugno 2020 e l'ora in cui il certificato sarebbe scaduto riceverà una notifica che il vecchio certificato non era più valido.

Se, tuttavia, il computer è l'orologio è stato impostato sul 1 agosto 2019, un utente malintenzionato che lo sapeva e che aveva il controllo della connessione Internet del computer poteva indirizzare i tentativi di connessione a una varietà di server fasulli, incluso uno che avrebbe affermato che la data era il 1 agosto 2019 e uno che affermasse che il certificato di yourbank.example.com non era stato revocato (a partire dal 1 agosto 2019, non lo sarebbe stato). Sebbene la capacità degli aggressori di sfruttare questo aspetto potrebbe essere limitata per i valori dell'orologio del computer che si trovano nel recente passato, più lontano è consentito il tempo, maggiori sono le possibilità di danno.

Tali problemi creano qualcosa di un catch-22 per i sistemi che saranno connessi a Internet solo molto raramente (ad esempio una volta ogni pochi anni) e potrebbero non conoscere la data in cui si connettono. Senza un mezzo per sapere se il certificato di un time server è ancora valido, non si avrebbe modo di sapere se l'ora riportata da quello che sembra essere un time server potrebbe essere manipolata in modo dannoso. Richiedere agli utenti di impostare l'ora e la data può essere approssimativo, ma se l'utente sta prestando attenzione, dovrebbe proteggersi da questo tipo di manipolazione.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...