159

Yes, you should notify the problem to the company - with caution. Update: a shorter, yet very complete answer was supplied by @crovers. But if you have patience... ...the problem here is not simply the possibility of tracking J. Random Stranger, but rather that: once your ID has been given to someone, apparently you cannot take it back and it does not ...


116

Yes. They ought to be using a long, unguessable string instead of a predictable, short one. I would consider this a security flaw that is relatively simple for them to fix. However, I would caution you - some companies do not handle situations like this very well. Some argue (in my view incorrectly) that changing that id constitutes hacking and they may ...


43

To add to the other answers - be aware of the risks of reporting the problem yourself: If you're inexperienced with reporting security issues, you might come across to them as dodgy and potentially malicious. A company that doesn't have experience with handling security issues might forward your report to the company lawyer rather than the IT department. ...


37

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


32

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


23

If I were you, I would say something like Hello, I have mistyped my ID (e.g. 12345) and pressed enter instead of backspace, and I was dumbfounded to find that the page loaded and found the location of a stranger who has the ID next to mine (e.g. 12346). Being able to track someone without their permission seems to be a security problem, as someone that ...


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


9

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


6

You are mixing separate things here, namely encryption software and password managers. For both tho, there is no way around storing the key in memory and the problems can be reduced to one: If you want to store passwords like in KeePassX, you have to unlock the password database once and keep it open (so you can autotype them via hotkeys). If you encrypt ...


6

Everyone else seems to be jumping the gun here. The key part to consider is HOW you an end user, share your location with other end users (family/friends). If you view the information with a link, and are able to send the same link to family members, then there is an assumption that you are posting information publicly (there is no authorization system). ...


5

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


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.


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


4

If you were to start a framework from scratch, you would have to catalog and address a wide range of possible vulnerabilities - from input sanitation to cross-site exploits, from authentication (and hashing, salting, password recovery, possibly data encryption) to resource access control. What I mean is, these are things you would need to do in abstract, ...


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

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.


4

First, AES-256-CTR (as labeled on one of the squares) is in fact a symmetric cipher. No assumption required. A more important aspect of this scheme is really preventing the CDN from changing files in an undetected manner. The link between the client and Telegram server is presumably trusted, and information to verify the legitimacy of files in the CDN is ...


3

Let's go through some possible 2-factor options and possible forms of attack: Non Google-voice SMS If someone steals your phone and can get past any lock: Any service that already trusted your phone as a device they will have full access to They have access to your email and can hijack trusted accounts that allow account password resets via email (though ...


3

Is there any plan to replace this protocol with something more reliable, or is it that most problems are implementation-based and all those best practices/RFCs are there to mitigate possible human error? There isn't a simple answer here, so I would "yes and no to all of the above". There are lots of factors at play. Is TLS flawed? Much like any other ...


3

If Alice signs the PDF before sending to Bob, it will look like this: source If Eve changes anything on the PDF, when Bob opens it, it will show something like this: source The signature contains the certificate of the issuer, and if anyone but Alice signs the document in her place, the signature will not be valid, and the PDF reader will show the ...


3

You are overcomplicating this. A counter of QR codes per day, daily salts, values that need to be synchronized... I would simply design the application having an ECC keypair. When A wants to give N points, it makes a 'coin' with the information (timestamp, sourceUser, points, expiry), signed with its private key. Then user B scans the coin and presents ...


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

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


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


2

The methodical approach to this is to go through a standard software security framework such as OWASP Software Assurance Maturity Model (OWASP SAMM Project) or BSSIM or any other other standard Software Security Maturity model. You need to properly identify the things such as Threat agents, Attack vectors, Security weakness, Security controls, Technical ...


2

Voting to close this as it is not a question about security. It is a question about software engineering and architecture: The best place to handle the exception is as close as possible to where the exception occurs - the separation of functionality is all about abstraction - the remote higher levels are separate because they don't know about what is going ...


2

Step 1: The auto incremented id implies you're worried someone would know the id one day. In that case they would know it on other days too. Step 2: If the salt isn't long enough, someone can find it by brute force if they know their own id, and then they'll be able to use the id they got in step 1 to create the md5 which is the userKey.


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


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