Tag Info

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 ...


25

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 ...


12

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 ...


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

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 ...


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 ...


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 ...


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