28,015 reputation
22766
bio website
location Troy, NY
age 30
visits member for 1 year, 11 months
seen 2 hours ago

2d
comment How can I prevent my database from being compromised if my CakePHP app is compromised?
@Dominicp yes, if you decrypt on the server then a persistent attack is still a problem, but it still prevents mass compromise of anything not accessed. If you really need Max security you could have decryption done client side but that'd be tricky.
Aug
18
comment Can we trust antivirus software?
@Agent_L - right, sorry if I wasn't clear, I wasn't disagreeing with you that a virus in a high privilege process isn't a bigger threat, but the question doesn't ask how much of a threat it is, it asks if we can trust AV software. There is no reason to suspect AV software any more than anything else, including the OS itself. I was just pointing out why I didn't mention your point in my answer.
Aug
15
comment How does iOS prevent unauthorised code from running?
@raz - sorry, I'm thinking as a developer where the OS itself is also an application of types. Beyond the kernel, most of the functionality is provided by applications that run as part of the OS, but any high privileged application could be used in theory. I switched it to use the term "high privileged code" to be more clear.
Aug
14
comment Fingerprinting the webpage content
If you are trying to do it without being noticed, that is almost impossible. If you want to do it in a way they can't work around, do something that it doesn't matter if they notice, just make it labor intensive to work around.
Aug
14
comment Can we trust antivirus software?
@Agent_L - they could have a more effective backdoor, but they aren't any more or less likely to have one.
Aug
12
comment What does one call the strategy of using “pre-password transforms” as passwords?
Google let me in is related to your google account as it is descriptive of it. You are trying to make easy to remember passwords in to something harder to recognize, but having it be harder to recognize is no more secure than the initial password is.
Aug
11
comment What does one call the strategy of using “pre-password transforms” as passwords?
@MarkC.Wallace - pretty sure it is more a class of things than a formal description. I've also heard "clever" password. They key is that it assumes that the user's system is smarter than what the attacker can reverse engineer, which is almost always a bad assumption and certainly not a reliable one.
Aug
11
comment What does one call the strategy of using “pre-password transforms” as passwords?
I have updated to include the names of the two things you seem to be describing, but there isn't an exact term because what you are talking about is universally considered a bad idea. Despite the fact you may not want to hear it, it is important to point out that these are bad ideas and thus it IS an important part of an answer.
Aug
11
comment What does one call the strategy of using “pre-password transforms” as passwords?
yes, but slow hashes don't protect against related passwords. If you had related passwords that you then ran through some convolution or hash, it is still trivial to guess the other inputs and test them. You don't have to try randomly, so the runtime doesn't matter. You are confusing finding random passwords with a rainbow table versus attacking a specific user across sites.
Aug
11
comment What does one call the strategy of using “pre-password transforms” as passwords?
if you are doing something that requires a computer to process it, then use a password manager and random passwords. If you are doing something that is remotely human readable, the algorithm is able to be reverse engineered. Also, we aren't talking about reversing a hash, we are talking about analysis of what is actually involved in producing it. Those are NOT the same question.
Aug
11
comment What does one call the strategy of using “pre-password transforms” as passwords?
I'd start with searching for "insecure". A consistent transform can still be universally broken by a mildly targeted attacker and is almost certainly highly vulnerable to things like frequency attacks, even by automated analysis. This is not a good idea. It may be a half measure better than using the same password, but not significantly.
Aug
6
comment Is it safe to send clear usernames/passwords on a https connection to authenticate users?
@Falco - and a programming error could result in the hash being insecure too. You have to validate behavior of security related code, not just hope it works right. The more complexity you add to a system, the harder it is to validate and the more likely an error or vulnerability is to appear. You have to judge how much benefit you get for a given amount of additional effort. Eventually the added risk of error in implementation is not worth the minimal gain in added resistance.
Aug
5
comment Is it safe to send clear usernames/passwords on a https connection to authenticate users?
Password/hash conversation continued in chat.
Aug
5
comment Is it safe to send clear usernames/passwords on a https connection to authenticate users?
Ah yes, I always remember GET is a bad idea because it is visible on the client system and may end up in client history, but forget that servers may log the parameters too.
Aug
5
comment Can an individual get an extended validation certificate?
Section 8.5 of that document makes it even clearer. It lists the valid entities explicitly and an individual is not one of them.
Aug
5
comment Is it safe to send clear usernames/passwords on a https connection to authenticate users?
@CodesInChaos - yeah, if you are using a sufficinently large intermediate hash and are sure it behaves well (truly random distribution) then it should be ok as long as the initial hash is salted and takes long enough to force use of a full enumeration of the intermediate hash space (or at least near full.)
Aug
5
comment Is it safe to send clear usernames/passwords on a https connection to authenticate users?
@CodesInChaos - Because nothing client side is trusted. An attacker can skip the entire slow process by bypassing the client entirely. You need to make sure you can't build a rainbow table of cheap, fast hash values. It isn't feasible if you salt each and provided the intermediate hash is long enough. Otherwise, you just make a rainbow table of hash values which can be generated at a very, VERY fast rate if they are cheap.
Aug
5
comment Is it safe to send clear usernames/passwords on a https connection to authenticate users?
@CodesInChaos - I'd only go for it being slightly less bad. Even using a complex hash to make a "longer" input, it is only key extension and an attacker is going to be able to produce a lot of cheap hashes very easily. Practically, it might not matter if the client side hash output is long and there are no vulnerabilities in either hash that limit the expansion from simple values. It's also important to note that in such a case, you would need to salt both the client and server side hashes. I'm still a bit dubious of the cost vs the benefit though.
Aug
5
comment Is it safe to send clear usernames/passwords on a https connection to authenticate users?
@AndyBoura - if you are designing the system such that you can support client side hashing, you have control over the network and server behavior for parts that would have access to the clear text. True, you aren't harmed by hashing it on the client (other than lost time), just so long as you it doesn't significantly impact the amount of hashing you do on the server.
Jul
30
comment pci compliance and temporary files
@mic.sca - good question. I think technically it probably wouldn't be, but I'm not sure that a lot of people consider that risk. It is at least slightly harder to access in a virtual memory file since it is more buried than if it is in a temp file, but technically it could still be compromised by dumping the virtual memory file.