The server keeps track of every player ID that ever connected successfully.
This database stores the last names and IPs used by the player and the
last countries the connections came from. Some stats are counted, like
"time connected" and "total tks". Most importantly, the database stores
rights (like admin) and restrictions (like ban). All rights and
restrictions are kept as dates (or timecodes), so, for example, if your
ban date is in the future, you are banned - and if it's in the past, you
can play. The collected stats are meant to help server owners at managing
players - especially, if they want to give someone admin rights.
The database is periodically saved to a file and read from that file on
startup. The default file is config/servervita.cfg and one backup is kept
in config/servervita_bak.cfg. During server start, if the regular file
can't be loaded, the backup is tried instead.
While the server is running, it checks periodically for a file named
config/servervita_update.cfg, and if the file exists, it is renamed to
a backup filename including a timecode and read and merged into the
database. The automatic rename makes sure, that a file is only read once.
Using such updates, a server owner can easily give several people admin
rights or for example, add clan tags for a whole list of IDs. (Yes, the
database also stores a clan tag for every ID...)
The database also stores two short comments for every ID. One can only be
read by server admins, but the other one is public. The public reason, for
example, can state a reason for a ban.
One database record takes up 264 bytes of RAM. During autosave, accounts,
that have not been used for a specified time (default 12 months), will
not be written. After a server restart, those old records will be gone.
Currently, there is no process in place, to also clean up old records
from RAM. Maybe, that'll be added later...
also clean up and fix some stuff: lilswap(unsigned long long int) mapped
to the 32-bit swap code...
added some runtime tests for the hash functions - now they will crash at
startup, if some test vectors fail (because big endian is still untested)
During startup, it is checked, if the game account needs to be unlocked
by password. If so, the password is asked and applied.
If no game account exists yet, the creation of a new account is offered.
new command "mypubkey": returns public key of game account, or empty
string, if no account exists or it is unusable (due to missing password,
for example)
DOCREF mypubkey
authkey manages a list of keys other than the game key (which is managed
by authsetup). For example, this can be server owner keys or clan boss
keys.
authkey clear
Empties the list and comments out all lines in config/authkeys.cfg.
authkey list
Lists all authkeys that are currently in memory.
authkey delete keyname
Deletes the key <keyname> from memory.
authkey new keyname
Generates a new key with the name <keyname>. If a key of that name
already exists, it is deleted. The key is added to the list in memory
and also written to the file config/authkeys.cfg.
authkey add keyname privkey
Adds a key with the name <keyname> to the list in memory. The privkey
is a 32-byte hexadecimal string, preferrably generated by authkey new.
The matching public key is generated automatically from the private key.
authkey selfcert keyname [comment]
Generates a self-signed certificate for the key <keyname>. Being able to
create such a cert is proof, that you own the private key of a certain
public key.
DOCREF authkey
authsetup contains all the funtionality needed to generate, load and save
private and public keys, and to lock and unlock the private key with a
password.
Private and public keys are used to authenticate the player to servers,
and are loaded from config/authprivate.cfg. Private keys can be stored
in an "encrypted with password" version - in which case the player has
to enter the password after game start. To prevent brute-force cracking
of the password, the key-derivation function uses a constant time to
encode (usually several seconds). Because of that, the decoding at game
start can be done in the background.
The private key is actually itself a public key generated from the
prepriv key. The prepriv key should be kept away from the computer, either
as hardcopy or on a thumbdrive. The prepriv key is not required to play
the game. It can be used to prove ownership of the private key, in case
the private key gets stolen. It can also be used to regenerate private
and public keys, in case they are lost. The prepriv key can also be
encrypted by its own password.
authsetup
checks private and public key and returns "1", if they match.
authsetup pre preprivhex [psalthex pwdcfg]
loads prepriv key into memory. optionally supports encrypted keys.
authsetup priv privhex [salthex pwdcfg]
loads private key into memory. optionally supports encrypted keys.
authsetup pub pubhex
loads public key into memory.
authsetup ppass preprivpass
decrypts prepriv key with password
authsetup pass privpass
decrypts private key with password
authsetup passd privpass [commandwhendone]
decrypts private key with password in background. optionally executes
cubescript command when done.
authsetup needpass
returns "1" if the private key needs decryption.
authsetup genpre [prelen]
generates new prepriv key.
authsetup genpriv
generates private key from prepriv key.
authsetup genpub
generates public key from private key.
authsetup newppass preprivpass [preprivfilename]
encrypts prepriv key with new password and saves the result to file.
The default filename is config/authpreprivate.cfg and an existing file
gets overwritten - but the former file content is kept and also written,
each line commented out.
authsetup newpass privpass [privatefilename]
encrypts private key with new password and saves the encrypted private
key and the public key to file. The default filename is
config/authprivate.cfg and an existing file gets overwritten - but the
former file content is kept and also written, each line commented out.
authsetup unarmed
sets private and public keys to a fixed value. For testing only.
Can be used to "log out".
authmemusage, authrounds, authmaxtime are only used, when new passwords are
created (authsetup new[p]pass). authmemusage is the number of megabytes
of RAM that are used for the password hash calculation. If authrounds
is zero (as is default), then the hash algorithm calculates as many
rounds as possible in the number of milliseconds specified in
authmaxtime. If authrounds is a positive number, then that is the number
of rounds to be done, regardless the required time. Note that, since the
password hash algorithm is not endianness-aware, it is not possible to
move an encrypted password to a machine with different endianness.
Moving between 32- and 64-bit machines should be no problem.
FIXME: the command is not blocked against use in multiplayer. It has to
be determined later, if this is a problem or feature. Especially
the background password calculation may be a problem.
DOCREF authsetup cryptodebug authmemusage authrounds authmaxtime
* FNV-1a: very fast, non-cryptographic hash
* bin2hex, hex2bin: hex ascii parser and hex string formatter
* ed25519test: vector test for all ed25519 functions
* ed25519speedtest: yep, that
The Ed25519 sources were taken from the crypto_sign/ed25519/ref
subdirectory of the SUPERCOP benchmarking tool.
The Ed25519 software is in the public domain.
Contributors (in alphabetical order)
Daniel J. Bernstein, University of Illinois at Chicago
Niels Duif, Technische Universiteit Eindhoven
Tanja Lange, Technische Universiteit Eindhoven
Peter Schwabe, National Taiwan University
Bo-Yin Yang, Academia Sinica
* basically a hash function that delivers keylen bytes calculated
from password and salt
* uses a lot of memory and a quite complex algorithm, to make
brute-force offline-attacks on short passwords as hard as possible
* last line of defense against "evil little brothers"
SHA512 was adapted from a few public domain sources and pseudocode from
wikipedia. The entropy collector gathers entropy from keyboard events and
mouse movement - and, just for fun, from screenshots.
The entropy pool is saved at program exit and reloaded at program start.
Entropy is used to re-seed the pseudorandom generator (not that it would
make a difference).
* do not use std::abs() because math.h includes one, that converts ints
to double. Use own iabs(), which directly uses labs() instead.
* don't use the word "gamma" as name for variables
* don't use a homebrew round() function
The light calculation requires the random generator to be seeded with a
constant - otherwise repeated light recalculations would make the lights
change.
This patch allows the random generator to go back to the state before the
static seed().
- fix possible crash in conc (but it's still an ugly hack)
- fix noob usage of strcmp
- flag some memory leaks (it would be nice, if the author(s) would clean
up the mess himself)
- fix crash in substr
- whitespace cleanup
there are plenty more memory leaks in command.cpp - for example, every
goto in cubescript does not clean up anything
the printf format "llx" can not be used on all platforms (for example,
mingw uses a different name for it)
this patch provides a function, that manually converts a 64-bit integer
to a hex string
Thx, Jpablon
ac-stef