| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | May 20 '12 at 21:36 | |
| stats | profile views | 55 |
|
Aug 31 |
answered | How would you store a 4 digit pin code securely in the database? |
|
Aug 31 |
answered | Brute-force heuristics used in password cracking |
|
Aug 30 |
comment |
Brute-force heuristics used in password cracking I believe J-t-R does use statistical (digraph frequencies) techniques to prioritise cracking efforts, as do other similar tools. There are sites for the specific purpose of sharing stolen/leaked password hashes (whether salted or not) and the corresponding cracked passwords. (Salting slows progress, but even with salting MD5 is susceptible to brute-forcing with GPGPUs -- particularly for <9 chars and/or letters-only -- and there are several tools that use GPGPUs to accelerate the cracking attempts. JtR can use substitution patterns (e.g. l33t) as well as wordlists and digraph frequencies. |
|
Aug 30 |
revised |
Passwords - any statistics on user behavior? added another reference |
|
Aug 30 |
revised |
Passwords - any statistics on user behavior? added another reference |
|
Aug 30 |
revised |
Passwords - any statistics on user behavior? added link |
|
Aug 30 |
answered | Passwords - any statistics on user behavior? |
|
Aug 29 |
comment |
Applying file deltas to an encrypted file What are the constraints, more precisely? Does "the network will be saturated sending deltas is preferred" mean that the network is saturated "up" (writes from clients to server) or "down" (reads) or both? Does "the client [might] not have version control" mean that the client may not keep a copy of the "previous version" of the file (which would allow it to calculate the delta itself)? Is it acceptable for the client to run any custom software at all, or must the server present a standard file server interface (NFS/CIFS/WebDAV/sftp/whatever) suitable for direct usage by the end-user? |
|
Aug 29 |
comment |
Applying file deltas to an encrypted file In "Files will be decrypted, have the delta applied, then re-encrypted" do you mean "the [VCS] file [containing the previous version(s) of the end-user file] will be decrypted, the delta to the new version of the end-user file calculated, the delta appended to the [VCS] file, and the [VCS] file re-encrypted"? Which bit of that "sounds a bit inefficient" -- the de/re-encryption of the VCS file? |
|
Aug 29 |
revised |
Best password strength checker typo |
|
Aug 29 |
comment |
How to best set up public WiFi without giving access to the rest of my network? $50 was NIC + the second "public" AP. Which might still be an overestimate -- I'm not in the US. |
|
Aug 29 |
answered | Best password strength checker |
|
Aug 29 |
awarded | Supporter |
|
Aug 29 |
awarded | Scholar |
|
Aug 29 |
awarded | Commentator |
|
Aug 29 |
accepted | Pre-hash password before applying bcrypt to avoid restricting password length |
|
Aug 29 |
comment |
Pre-hash password before applying bcrypt to avoid restricting password length ... and luckily (or by design?) 64 or 128 bits (8 or 16 characters) of random salt with the 256 bits (32 characters) sha256(password) output does fit within the 55 char bcrypt() limit. Thanks. |
|
Aug 29 |
comment |
Pre-hash password before applying bcrypt to avoid restricting password length Thanks, now fixed |
|
Aug 29 |
revised |
Pre-hash password before applying bcrypt to avoid restricting password length edited body |
|
Aug 25 |
asked | Pre-hash password before applying bcrypt to avoid restricting password length |