Tag Info

New answers tagged

1

We had a highly escalated support case once about passwords being printed in the log file and as you can imagine, management jumped into fire-fighting mode, directing the devs to fix it 'by all means necessary.' I'm not sure which language you're using, but here are the several measures that can be taken: Some logging frameworks themselves have filtering ...


1

I'm assuming that this isn't the best practice as the smart but naughty user could loop through all the possible combinations of the PIN code and wait which one will give him true as a response. This is called a "brute-force" attack. In principle, it is impossible to prevent brute-force attacks. There is simply no way to set up a password scheme that ...


4

Is there a reason you need this method in your business classes at all? I can't see any reference to this or to other member fields, meaning it's a disconnected utility method that can happily sit in a UserProvider sort of class, a service that is probably orthogonal to your actual business domain. If you do want to have it as part of your objects, you can ...


-1

I agree with Alexus. Below is the interface that would go with your abstract above. You cannot put logic into an interface so this is all you get. public interface ISecurity{ GenericPrincipal PrincipalIdentity(); }


2

Its a multipart piece of information you need to communicate. First off, you provide the timestamp. That is what you validate against for the 'was submitted within 15 minutes'. Secondly, you have a hash of the timestamp with some additional salt. The salt is known only to you (on the server). If the time stamp was altered, the hash of the altered time ...


0

I would look at reworking the way you save your data. Profile can exist without picture, while picture can't exist without profile. So, once people are done with their profile, save it. Once they are done with picture, save it separately. Why separate the registration into a number of pages, if you don't save the data independently?


0

Generally, your session name with be PHPSESSID (unless you rename it with session_name - like you've proposed). This really gives no extra benefit in terms of security, here's why; You've mentioned that you're aware sessions can get stolen, which is correct (session hijacking), though the name itself (Alice, Bob) introduces no security measure in this (not ...


1

The Same Origin Policy protects the client. CSRF tokens protect the server. SOP prevents malicious site A from accessing cookie credentials held by the client for site B which would otherwise be submitted along with the cross-origin request. See How do web servers enforce the same-origin policy? (short answer: they don't) The link in the other answer ...


2

It is quite easy to get frustrated with management in these situations but keep in mind that your company only exists to make money. Having a super useful and secure application is not necessarily a worthwhile goal from a manager's point of view. You have not mentioned in what format the data is pushed to clients but if it is in HTML form then have you ...


2

yes, your manager is right - security flaws don't make themselves, they were all produced by a developer who didn't consider every case. Because software can be complicated, we can all be guilty of this. So you design a system defensively to help prevent us from screwing up. One day some requirement will come in that requires eval, and then.. So, you can ...



Top 50 recent answers are included