security
UPDATED on Nov28, 2009 – See previous version at security0
Real security doesn’t thrive on keeping how it works a secret. Here we explain what a hacker would have to do to crack a norbt.
Cracking a norbt means finding out the text without knowing the answer.
Cryptography used on a norbt
Let’s assume that the hacker gets access to the server and obtains the data stored there.
The data stored on the server for a norbt is:
answer: HMACSHA1(answer, salt1) , salt1
text: AES128(HMACSHA1(answer, salt2), IV, Mode.CFB, text), salt2, IV
For the hacker to crack the text she will have to break either HMACSHA1(answer, salt1) or AES128 directly.
Listening to traffic won’t work to break a norbt because all encryption and decryption operations are performed in the browser. If the hacker breaks SSL to look at the traffic she won’t get any more data than what is stored on the server.
No attack with the web page data
When a browser requests to view or manage a norbt, it gets: mod(HMACSHA1(answer, salt1),64), salt1. So the browser gets a number between 0..63 and a salt. A brute force attack with this data is not possible. A hacker that tries to perform a brute force attack will have to check with the server on 1 of every 64 attempts.
Strong Answer = Strong norbt
In most cases the answer will be the weakest point of a norbt. If an answer is easy to guess or if there are a limited number of options (example: which country do I live in?) then it is easier to try all possible options and come up with a correct answer. If your answer is strong then your norbt will be almost unbreakable.
Your norbt is as secure as your answer. To crack a norbt without guessing the answer, the hacker has to break either HMACSHA1 or AES, which are cryptography standards that the security world uses (banks, governments, secure USB keys, military, computer passwords…).
We take the security of your data seriously.
wikipedia references:
AES
SHA
Salt
Hacker
[...] to trust any secret missives to Norbt without a better idea of how they secure your text, check out their security page. And while we wouldn’t put any of our most sensitive data in Norbt, it is, at the very least, [...]
[...] info missives to Norbt without a meliorate intent of how they bonded your text, analyse discover their section page. And patch we wouldn’t place some of our most huffy accumulation in Norbt, it is, at the [...]
SHA-1 is no longer considered a cryptographically secure hash function. There exist collision attacks for the function well below its birthday bound. In addition, you should be using a key derivation function, such as PBKDF2 instead of simple hashing to generate your AES key. It’s important to note that the collision attacks for SHA-1 do not affect its HMAC counterpart, so HMAC-SHA-1 being the default pseudorandom function for PBKDF2 is fine. A simpler, but less-tested way to generate a key could be SHA-256(salt + answer SHA-256(salt + answer)). This prevents the length extension attack of which Merkle-Damgaard hash constructions (such as the SHA family) are known to suffer.
Further, CFB mode is not recommended for use due to the lack of a guarantee that there will be no short loops. In a nut shell, CFB uses the output of the cipher as the next input (http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher_feedback_.28CFB.29 ). Should this output repeat itself, the keystream generated by the cipher will also repeat itself (and if the plaintext is the same, the ciphertext will also repeat itself), leaking a large amount of information. You should instead be using CBC or CTR mode, which are not affected by such weaknesses.
A new security model has been released. This page has been updated to honor the current implementation. Previous version of this page can be found at: http://blog.norbt.com/security0/
norbt’s created in the past will use old security model.
New norbt’s will use current security model.
[...] received some suggestions via the comments and also from comments on Bruce Schneier’s blog to improve the security of [...]