Unix Timestamp dalam Keamanan dan Autentikasi — Kedaluwarsa Token, Sesi, dan Rate Limiting

Waktu adalah “primitif” keamanan. Kedaluwarsa token, timeout sesi, jendela rate limiting, dan pencegahan replay attack semuanya bergantung pada pengukuran waktu yang akurat — dan di sistem modern, pengukuran itu hampir selalu memakai Unix timestamp.

Memahami cara kerja Unix timestamp dalam konteks keamanan membantu Anda men-debug kegagalan autentikasi, merancang sistem sesi dengan benar, dan menghindari kerentanan umum yang muncul karena kesalahan menangani timestamp.

Gunakan Unix Timestamp Converter untuk memeriksa nilai timestamp tertentu dan mengubahnya menjadi tanggal yang mudah dibaca.

Kenapa Unix timestamp bagus untuk keamanan

Unix timestamp adalah bilangan bulat tunggal yang merepresentasikan jumlah detik sejak 1 Januari 1970 UTC (Unix epoch). Representasi sederhana ini punya beberapa sifat yang relevan untuk keamanan:

Tidak bergantung timezone. Timestamp 1720000000 berarti momen yang sama di mana pun di Bumi, terlepas dari timezone lokal. String datetime seperti “2024-07-03 14:00:00” ambigu — jam 14:00 di timezone mana? Unix timestamp menghilangkan ambiguitas itu. Pengecekan keamanan yang membandingkan waktu lintas sistem di timezone berbeda tidak akan meleset karena interpretasi timezone.

Aritmetika mudah. Memeriksa apakah token yang diterbitkan pada iat sudah kedaluwarsa dengan jendela 1 jam cukup: current_timestamp > iat + 3600. Tanpa “calendar math”, tanpa parsing datetime, tanpa penyesuaian daylight saving. Perhitungannya tepat dan cepat.

Penyimpanan ringkas. Integer 32-bit atau 64-bit lebih kecil dibanding string datetime berformat. Untuk sistem yang membuat dan menyimpan jutaan token, sesi, atau log, ini berdampak.

Kedaluwarsa token JWT: claim iat, exp, dan nbf

JSON Web Token (JWT) memakai Unix timestamp untuk claim yang berkaitan dengan waktu:

iat (issued at): Unix timestamp saat token dibuat. Dipakai untuk mengukur “umur” token dan mendeteksi token yang dibuat jauh di masa lalu.
exp (expiration time): Unix timestamp setelah itu token tidak boleh diterima. Server memvalidasi current_time > exp — jika benar, token kedaluwarsa dan ditolak.
nbf (not before): Unix timestamp sebelum itu token tidak boleh diterima. Lebih jarang dipakai, tetapi berguna untuk token yang dibuat lebih dulu dan baru boleh valid di waktu tertentu.

Contoh payload JWT:

{
  "sub": "user_12345",
  "iat": 1720000000,
  "exp": 1720086400,
  "nbf": 1720000000
}

Di contoh ini, exp - iat = 86400, artinya token valid tepat 24 jam (86.400 detik).

Kesalahan umum: mengatur expiry dalam milidetik. Karena Date.now() di JavaScript menghasilkan milidetik, developer kadang menghitung exp sebagai Date.now() + 86400000 (menambah milidetik ke timestamp milidetik). Jika library JWT mengharapkan detik, ini menghasilkan token dengan expiry “1.000× lebih besar” (seolah-olah ribuan tahun di masa depan) alih-alih 24 jam. Di JavaScript, selalu bagi 1.000: Math.floor(Date.now() / 1000) + 86400.

Untuk memeriksa expiry JWT: decode payload base64 dan lihat exp. Tempelkan nilainya ke Unix Timestamp Converter untuk melihat waktu kedaluwarsa yang bisa dibaca manusia.

Timeout sesi dan sliding window

Sesi aplikasi web biasanya memakai timestamp untuk dua jenis timeout:

Absolute timeout: Sesi kedaluwarsa pada waktu tetap setelah dibuat, terlepas dari aktivitas. Implementasi: simpan created_at (unix timestamp) saat sesi dibuat. Pada setiap request, cek current_time - created_at > max_session_seconds. Jika benar, invalidkan sesi dan minta login ulang.

Sliding timeout (idle timeout): Sesi kedaluwarsa setelah periode tidak aktif. Setiap request memperpanjang jendela. Implementasi: simpan last_active (unix timestamp), di-update pada setiap request. Cek current_time - last_active > idle_timeout_seconds. Jika benar, sesi sudah terlalu lama idle dan kedaluwarsa.

Kebanyakan aplikasi butuh keduanya: sliding window untuk kenyamanan (tidak logout saat aktif digunakan) dan batas maksimal absolut (sesi tidak valid “selamanya” walau terus aktif). Kombinasi umum: idle timeout 30 menit, absolute maximum 8 jam.

Implementasi contoh: `python if current_time - session["last_active"] > 1800: # 30 menit idle invalidate_session() if current_time - session["created_at"] > 28800: # 8 jam absolut invalidate_session() session["last_active"] = current_time `

Jendela rate limiting

Rate limiting biasanya berjalan dalam jendela waktu tetap yang diukur dalam detik. Implementasi yang umum:

Fixed window: Izinkan N request per window. Window adalah periode seperti “per menit” atau “per jam”, didefinisikan sebagai rentang Unix timestamp. Window untuk menit saat ini adalah floor(current_time / 60) * 60 sampai nilai itu + 60. Saat request masuk, naikkan counter yang di-key dengan timestamp awal window. Jika counter > N, tolak.

Sliding window: Lebih akurat daripada fixed window. Simpan timestamp dari setiap request dalam N detik terakhir. Pada request baru, hitung berapa timestamp yang berada dalam current_time - window_seconds sampai current_time. Jika count >= limit, tolak; jika tidak, catat timestamp baru.

Sliding window mencegah masalah “batas window” pada fixed window (misalnya pengguna bisa melakukan N request di 11:59 dan N request di 12:00 sehingga total 2N dalam dua menit berurutan).

Untuk sistem terdistribusi dengan banyak server, rate limiting butuh shared store (Redis umum). Counter atau daftar timestamp disimpan dengan TTL sebesar window agar otomatis kedaluwarsa. Key sering berbentuk ratelimit:{user_id}:{window_start_timestamp}.

Mencegah replay attack dengan timestamp

Replay attack terjadi saat penyerang menyadap request yang valid lalu mengirim ulang request tersebut agar aksi yang sama terjadi lagi. Timestamp membantu memperkecil peluang itu.

Nonce berbasis timestamp: Sertakan Unix timestamp saat ini dalam signature request. Server penerima memeriksa apakah timestamp masih dalam toleransi (misalnya ±5 menit dari waktu server). Request di luar jendela ditolak meski signature valid. Ini membatasi jendela replay menjadi 5 menit — belum sempurna, tetapi mencegah replay tanpa batas waktu.

Keterbatasannya: jendela 5 menit masih memungkinkan replay. Untuk benar-benar mencegah replay, Anda juga perlu menyimpan dan memastikan kombinasi timestamp+nonce belum pernah dipakai (biasanya di cache berumur pendek dengan TTL sama dengan jendela replay).

TOTP (Time-based One-Time Password): Aplikasi seperti Google Authenticator memakai Unix timestamp untuk membuat kode berbasis waktu. Window 30 detik (floor(current_time / 30)) dipakai sebagai input HMAC bersama secret yang dibagi. Kode berubah setiap 30 detik sehingga replay di luar window tidak mungkin.

Clock skew dan sinkronisasi waktu

Keamanan berbasis Unix timestamp hanya bekerja jika jam tersinkronisasi. Jika jam klien 10 menit lebih cepat dari server, klien bisa menghasilkan JWT dengan exp yang “aneh” saat divalidasi — atau token dengan nbf yang belum valid menurut sisi lain.

Praktiknya:

Server sebaiknya memakai NTP (Network Time Protocol) agar jam sinkron sampai tingkat milidetik
Validator JWT sebaiknya mengizinkan toleransi clock skew kecil (1–5 menit) saat memeriksa exp dan nbf
Jangan percaya timestamp dari klien untuk keputusan keamanan — gunakan timestamp server untuk iat, exp, dan audit log

Unix Timestamp Converter menampilkan timestamp saat ini menurut browser Anda. Jika Anda sedang men-debug ketidakcocokan, bandingkan dengan date +%s di server untuk melihat apakah ada drift.

Signature HMAC dan request yang di-key dengan timestamp

Banyak sistem webhook dan skema autentikasi API (AWS Signature Version 4, verifikasi webhook Stripe, webhook Shopify) menyertakan timestamp dalam konten yang ditandatangani. Signature melindungi payload dan timestamp, dan penerima memvalidasi bahwa:

1. Signature cocok (payload + timestamp tidak diubah) 2. Timestamp masih dalam jendela yang dapat diterima (request tidak basi atau replay)

AWS SigV4 memakai format tanggal (YYYYMMDDTHHMMSSZ) alih-alih Unix timestamp, tetapi logika dasarnya sama — waktu menjadi bagian dari data yang ditandatangani, dan request dengan timestamp di luar jendela (umumnya 15 menit) ditolak.

Saat men-debug kegagalan verifikasi signature webhook, salah satu penyebab umum adalah timestamp basi — jam pengirim meleset, atau ada delay pengiriman yang besar (queue, retry) sehingga timestamp keluar dari jendela yang diizinkan.

Men-debug kegagalan autentikasi terkait timestamp

Kegagalan autentikasi yang paling sering terkait timestamp:

1. Token kedaluwarsa: Periksa exp dengan mendecode JWT dan mengonversi exp ke tanggal. Unix Timestamp Converter bisa melakukannya cepat. 2. Token belum valid: nbf berada di masa depan. Periksa apakah token dibuat dengan waktu mulai yang memang di-set ke depan. 3. Clock skew: Jam server dan klien tidak sinkron melebihi toleransi. Periksa keduanya dengan referensi. 4. Milidetik vs detik: Timestamp 13 digit dipakai saat yang diharapkan 10 digit, atau sebaliknya. Token dengan exp: 1720086400000 (milidetik) pada dasarnya “tidak akan kedaluwarsa” dalam skala manusia — itu mewakili tanggal puluhan ribu tahun ke depan. 5. Kebingungan timezone saat logging: Log tampak “melenceng” karena ditampilkan dalam waktu lokal, sementara perbandingan timestamp menggunakan UTC. Unix timestamp selalu UTC; formatkan secara eksplisit saat ditampilkan.

Install this app