What is it with requiring at least 6 character usernames? Why does it matter to an automated system if I use less? I get that a username with only one letter isn't optimal, but I don't see why it can't be > 3.
Right, so make 5 the minimum then and reserve certain words. I guess I can always use usernames such as "administration", "dashboard" or "profile", right? I believe setting a minimum of 6 letters is a questionnable approach to this problem.
Totally understandable - we don't want to exclude you based on the number of characters in your desired username. We just don't have a good set of all the words we need to reserve upfront - what we really want to avoid is ever forcing someone to change their username because of a conflict like this.
We'll see what we can do to allow shorter usernames without ending up in this situation. Thanks for the feedback.
This article is just an analysis of one of the inherent and well-documented weaknesses in truecrypt: the fact that the encryption key must stay in RAM the entire time you are using an encrypted volume. So, as has always been the case, treat the contents of your RAM as precious when a truecrypt volume is mounted.
Unless you're using a trusted computing environment, right? In which case, if you trust the processor and startup environment, the kernel can be assured to run safely and prevent such attacks. Correct?
Well, in theory, let's say you've got a laptop encrypted with Truecrypt. You put it in sleep mode instead of switching it completely off or hibernating,because you are just nipping out for a coffee. An attacker could then steal it, lower its temperature(let's say they put it in a freezer for a while), and then extract - literally take out - the RAM from that machine and plug it into a specially prepared station which would then be used to extract the contents of that memory. In low temperatures, RAM data retention is measured in minutes, so all data you had in your system would be preserved, including the encryption key.
Unlikely? Quite, unless someone like NSA or FBI want your data. Possible? Yes, with the right resources.
Note the comment at the end of the paper. The authors had not been able to do it successfully with their relatively simple methodology. Sure it is harder than DDR2 but this doesn't mean it is impossible. As pointed out by the authors, the failure can simply be due to the memory controller implementation (or DDR3 protocol itself) on their test setup. If this is the case, then all it takes is a custom memory controller that is optimized for this type of extraction.
It means if you're worried about the contents of your encrypted drives being uncovered, you need to make sure no malicious processes gain access to a dump of your system's memory while it's booted / running / encrypted drives are mounted.
You're correct - it does map Dropbox, Google Drive and Box to removable drives on Windows, and it also allows you to mix multiple accounts from (say) Dropbox so you can have a work and personal account mounted at the same time. It's not currently a webapp, although we have plans to create one.
Nice idea, but I hated the workflow of setting up an account - first I have to type in a phone number manually twice, which is easily readable from Android. I also missed an explanation why I needed to set up an encryption token rightaway (I get what the point is, I'd just much rather try using the app first without having to set up all kinds of passwords and credentials first).