22,974 reputation
21856
bio website
location Troy, NY
age 29
visits member for 1 years, 7 months
seen 1 hour ago

Mar
20
comment What are the problems that Chip card technology solve? and what are the problems EMV solve? Are the separate things?
@KristoferA - for there purposes it is still secure as soon as magnetic strips go away. If you can't make a purchase by knowing just the card number and other mag-stripe details, then it is no security issue for them to be known but still lets the vendor track the purchase more clearly. Until we get rid of mag stripes, it doesn't matter since the stripe is needed for compatibility with mag stripe only readers.
Mar
20
comment What are the problems that Chip card technology solve? and what are the problems EMV solve? Are the separate things?
@KristoferA - what does it matter if the PAN is provided if it can't be used? If they scanned the card, they could have captured the magnetic strip anyway. You can't clone a chip with just the information on the magnetic strip. What matters is the private key that is unique to the card which must sign the challenge to prove the card was present. This is never revealed.
Mar
19
comment Should generating gpg keys ever result in an identical key to an older key?
@user12588 - if you can't use the new private key with the old public key then they aren't identical. They would be the same file size, but the contents would be different.
Mar
18
comment Why is client-side hashing of a password so uncommon?
@muis the salt need not be protected. Store it on the server and send it to the client before hashing. If the server can't be trusted for this, still use the domain name and user name appended to the server supplied data perhaps.
Mar
18
comment Review of approach to client-side only hashing and encryption for web application
That is in fact the preferred and pretty much only way to secure a local application since all operations and unencrypted data are inherently untrusted. The entire basis of trust is in the user holding the secret and trusting the computer when they use it. Trusted computing when available offers a little more protection but is far more complex and not particularly widely available.
Mar
18
comment Review of approach to client-side only hashing and encryption for web application
@AdamMarshall - you can store a known value encrypted. So when I first enter my password, the application stores the value. "I am me" in the DB. When I enter my password to authenticate, the key is derived, the encrypted value is decrypted and the code checks to see if it says "I am me". If it is, then I entered the correct password, if not, I entered an incorrect password.
Mar
18
comment Why is client-side hashing of a password so uncommon?
@Muis - my point is simply that you should treat the hash generated client side as if it was the user's own password when dealing with it server side. It isn't bad to use a client side hash to protect the user's password from being exposed to the server, but it practically acts like the user's direct password as far as the server is concerned.
Mar
18
comment Why is client-side hashing of a password so uncommon?
@Muis my point is that the salted hash isn't useless. It can compromise the integrity of your authentication system as it is the new password for authentication (even if not for encryption). The attacker could still get the hash from the DB on the server and convince the server that they are the user and access the encrypted copy of the files (which granted, they may have access to already anyway at that point). Additionally, a salt should be globally unique, not a domain name.
Mar
14
comment DNS zone size overload?
I'd say if your DNS server is able to accept unauthenticated creation of DNS zones, you have much bigger problems than a DOS attack.
Mar
13
comment Protecting server from physical access?
@user3200534 - yes, but you still have to store decrypted data and that could be accessible. Physical access allows any number of bad things to be done to your system. If you don't have physical control of the hardware you can't trust it and any trusted operation you do on it is compromised. You can try and limit the damage some, but either way, that still isn't physical security which is what you asked about. It sounds like you are actually trying to ask if there is anything you can do to make untrusted hardware trusted.
Mar
13
comment Protecting server from physical access?
Full disk encryption is invaluable for protecting data at rest but does almost nothing for data in flight other than make an extra hoop to jump.
Mar
13
comment Protecting server from physical access?
@user3200534 - those don't secure from PHYSICAL access. They secure data and processes. A running server must have keys in RAM and if you have physical access it is conceivable to pull that data out of the hardware in flight while decrypted (including potentially pulling the keys themselves). When someone has complete physical control of your running box, as you use it, you are done.
Mar
13
comment Protecting server from physical access?
That or you can always try a land mine in front of the server rack and a shotgun in the cabinet with the trigger tied to the door. ;)
Mar
6
comment Installing profile on “Good” Mail application give someone admin permission on my iPhone
Additionally, do you trust that Good placed sufficient security around their control protocols to avoid hijacking of the wipe controls.
Mar
4
comment Wouldn't transient cookies for session management increase effectiveness of MITM?
@ole session ids should be impossible to guess and if a transient cookie is used then unless the local machine is compromised then the key isn't going to leak. Killing the cookie on browser close is the best possible option since you need some way to keep a session. Yes it is best if they actively log out but there is no way to force that and no substantial attack against the cookie that couldn't be taken against the logout anyway.
Mar
4
comment Wouldn't transient cookies for session management increase effectiveness of MITM?
@OleMartinHandeland - MITM how? If it is only exchanged over SSL, then MITM isn't possible. If user's machine itself is compromised, the attacker could prevent any attempt to log out too and make it look like clicking the logout happened when really they do their own thing.
Mar
4
comment Are virtual keyboards themselves secure?
@user3280126 - most of the claims seem fair and if the company is trust worthy, it would avoid a few possible keylogger mechanisms, but they provide no evidence of how they supposedly counter the most common type of OS event keylogger. Without exposing a direct interface to the keyboard from an application, I don't know how else they plan on sending the events to avoid OS events being fired. My guess is they are probably copying and pasting the character rather than using a keystroke and then clearing the paste buffer, but a good keylogger should still be able to pick that up.
Mar
4
comment Are virtual keyboards themselves secure?
@user3280126 - your entire premise itself is wrong though. Virtual keyboards provide zero protection against keyloggers. Keyloggers don't look at the input from the keyboard. Keyboard input goes directly to the OS. Keyloggers look for key press events published by the OS and virtual keyboards cause the exact same events to fire. To a keylogger, it doesn't matter where you press the button. You can never get around that because the application itself looks for the OS events. The only way would be for the application itself to provide a virtual keyboard. That could avoid the OS entirely.
Mar
4
comment Are virtual keyboards themselves secure?
possible duplicate of Protection against screenshot key loggers
Mar
2
comment two encrypting / hashing case, which one is best
Right, unless I missed something the second example is just the second half of the first. The second part of it is fine as long as the iterations are high enough but the first call is just a waste of time.