Hot answers tagged

36

I am not aware of any definitive, "official" answer on this subject, but this seems to be part of an attempt at genericity and coherence. In the SSL/TLS standard, all messages follow regular encoding rules, using a specific presentation language. No part of the protocol "infers" length from the record length. One enlightening detail is the ClientKeyExchange ...


28

For TLS with the purpose of liveliness (keep-alive) checks, there's no reason to: Encode a payload size field in the heartbeat request/response header (the length of the payload comes from the record layer rrec.length in OpenSSL code -- you just have to subtract off the fixed HB header size from this), Allow HBs to be variable size -- a small HB size (in ...


14

If you look into RFC6520 (heartbeat extension) there is a padding after the payload. So the length is required to know where the payload ends and the padding starts. Apart from that I find the design overengineered: the both reasons for this extension seem to be to make PMTU possible (by using messages of different size) and by having heartbeat to know if ...


11

Ok, let's walk through the several possible scenarios here. 1) Display exactly what is wrong with the login attempt This is obviously a stupid thing to do. By displaying exactly what is wrong with the login attempt, you are helping an attacker narrow down his attack. This is the reason why people recommend displaying a more generic message like Invalid ...


8

What about : Security Theater? Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it. Some experts such as Edward Felten have described the airport security repercussions due to the September 11 attacks as security theater. ...


5

I will assume that clients answer a series of n boolean questions. The server stores their answers in such a way that you that admin can not know their responses. Then the server identifies pairs of clients with identical responses. Then could not you the admin (or anyone really) create 2^n dummy accounts (all possible responses to the boolean questions). ...


5

You already answered the question youself: The only way to not give away any information is to display a generic "A message has been sent to a@b.c" after requesting a passwort reset, even if there is no account associated with that email. See also this question for additional details.


4

An "ATM room" is more meant to give to the customer a feeling of security than actual security. For a bank, "security" means "security of the bank" so it will want to protect the really valuable thing (in the eyes of the bank), and that's the machine itself and its belly full of money. Therefore, bank ATM are normally integrated in the load-bearing wall of ...


4

There are two strong options: Strong password requirements. This negates the problem, by forcing the user to use a strong password. It will, however, reduce conversion rates if people get frustrated. Single sign-on. This involves using a 3rd party service (e.g. Facebook, Twitter, Google, OpenID, etc.) as a login service, meaning you don't actually need to ...


3

and to accomplish the goal you have to find the key value. Do you really need to recover the key to accomplish the goal? The scheme you have described is vulnerable to the classic length extension attack where a hash function is misused as a message authentication code. The attack is described very well in the Wikepedia article so I shall avoid ...


3

The main problem with this would be when someone has malware on your computer (such as a keylogger) they would be able to get your Google Voice password as well as your normal account password. They could then get past the two factor authentication. If you always access Google Voice from a separate system you'd still technically be two factor though.


2

The most current documentation already posted (by the Trike team, anyway) is in the Help spreadsheet, which you can find here: http://sourceforge.net/apps/trac/trike/browser/spreadsheet/trunk/docs/help/TrikeHelp.xlsx I also have a very rough draft of the documentation for how to actually do the first half of the methodology using the spreadsheet. I am ...


2

What you are describing is multi-factor authentication, the first factor being the proximity of the 2 devices. Therefore it does not violate established principles, but rather is becoming standard practice rather than as a response to a high profile attack. The devices involved need to know that the communication is being performed when only the user wants ...


1

Deprecated functions are generally tagged by static code analyzers simply because they're deprecated. (That's usually an optional setting.) Many secure coding standards specifically state: "do not use deprecated functions." Apart from some long-ago-fixed bugs, gethostbyname isn't terrible, but that's no reason to use it in new code when a supported ...


1

This may be the case that the original user's session continues to live in the server and the original session key continues to be acceptable (even if it is not readily available in a cookie). Some minor security risks involving leaving the server-side of sessions hanging around include increasing the time window where a session hijacking is possible and not ...


1

This doesn't seem to be a vulnerability. Even if you would allow a user to log in multiple times on the same page, this doesn't imply any security flaws because the session and user management could still be secure. However, being logged in as multiple users is a design flaw. If you can login again as a logged in user, the panel should be redesigned to ...


1

I'm not a security expert but my reasoning is the following: If you encrypt the information using shared key (known to you) then you can decrypt data on server and compare it. If you encrypt data on the clients using individual keys you can not decrypt the data but you cannot compare them. I see two solutions Simple - hash the data (using shared secret) - ...


1

All these terms have a lot of play in the joints, of course. But I think I tend to agree with the question author here: I would hesitate a little to use the labels "security theater" or "security by obscurity" re. the situation the OP offers up. "Security theater" is most often applied where the person who puts or keeps the supposedly effective security ...


1

Unauthorized Data Access at Server I suggest you're thinking about this problem backwards. The vulnerability is at the server, and therefore, you should just call as you see it. Obfuscation is a type of Security Through Obscurity; there's nothing inherently wrong with it unless you believe it more secure than it really is (like your colleague). Client side ...


1

No, although the reason I see is independent of most of your post. CBC mode is malleable; you should use a MAC too.


1

Sorry guys but I cannot accept Your answers because they are just repeating what I believe is 'general knowledge' (or worse - "industry standard") without second thoughts. So, I made some research myself, read some topics about this subject and found how good websites work with this matter.. And it looks like site we're using to discuss this subject (and I ...


1

Rely on Facebook for authentication. (I.e. use single sign-on exclusively.) Weak passwords aren't your major concern, actually. People can always change their password later. (They won't, of course, but so what? Who'd bother to use a strong password for an athletic department, even if it's for more than a free T-shift?) The real problem is that people will ...



Only top voted, non community-wiki answers of a minimum length are eligible