Tag Info

Hot answers tagged

46

Why are you refusing to use TLS? It works, it has a good track record (some minor exceptions aside). Refusing to use good tools without a compelling reason does not engender confidence and does not immediately suggest professionalism. Additionally, do not roll your own authentication system. That is silly, and you will make mistakes. Instead, since you ...


18

A) Yep you got it. Same in that they both result from a failed login attempt(s), though they differ in things like logging, the resulting UX implementation, and when one is used. If a user is temporarily locked out, this is email-worthy. You should send an email or text-message to them notifying them that enough failed attempts were made to warrant a ...


17

SSL/TLS certificates will be free by Q2 2015. Get the certificate here: https://letsencrypt.org/ Let's Encrypt will offer domain-validated certificates signed through IdenTrust at no charge. When this goes live, these questions should be closed, IMHO


10

What could be other good advices, to achieve as much security as I can without using SSL? You can use TLS instead of doing anything stupid.


10

What you are trying to do is impossible without a secure way of sending your files to the client, such as TLS. Your approaches of hashing the password client-side require the javascript to be securely sent to the client. Otherwise, a MITM could simply serve a script that does not hash the password, but instead send the clear text password directly to them. ...


10

Two-factor or multi factor authentication is based on three possible forms of authentication: Something you know which is considered secret (password) Something you have (token, SMS token, card,...) Something you are (biometrics) If either two of these three are combined, you can speak of two-factor authentication. Saying two things you know (such as two ...


7

"Throttling" and "temporary lockout" are exactly the same thing. It is likely, however, that your dev team misunderstood the concepts, and assumed you meant "throttling" like most of the other answers here did (with the exception of @R15, though that is less an answer and more of important considerations). The important point that they are missing is ...


5

I see at least one way an attacker can take advantage of these e-mails. The attacker (perhaps one of your customers) might attempt to "claim to be you" and send an e-mail to your customers with a very similar link, to a faked version of your website. When the victim user "logs in" to the faked site, the attacker would then have their username and password, ...


4

First, may I ask why you think the app is not as secure as the website? Generally speaking, from a security perspective, one of the worse things you can possibly do is to involve PHP, which has more security pitfalls then, well, probably all of the other common technologies combined. Additionally: if you're any sensitive traffic from the app to the ...


4

unserialize allows the creation of arbitrary object constructs of any class with arbitrary attributes. During deserialization, the lifetime of an object, and the interaction with the object, several methods including magic methods may get called using these arbitrarily definable attributes. An attacker may be able to utilize the functionality provided within ...


4

When you are browsing TOR hidden services, the TOR system already provides end-to-end encryption, so another TLS layer is redundant. It is in fact counter-productive, because one of the goals of TLS is to de-anonymize the server. It makes no sense to go through the trouble to set up a hidden service and then get a certificate from a certificate authority ...


4

Cryptographically secure voting is difficult because voting encompasses so much. Let's take, for example, vote-buying or coercion. Imagine a system where I can vote, and can verify that my vote was tallied correctly. Now I can provide that proof to a third party who purchased my vote to claim renumeration for that vote. If the voter cannot verify their ...


3

CAPTCHAs are one area of computer security where "roll-your-own" can be a good idea. In order to break a CAPTCHA, a bot needs to be programmed to recognize and solve the CAPTCHA. For low-volume, low-value sites, the cost to program a bot to handle even a trivial CAPTCHA such as this is greater than the expected value of breaking it. By the simple ...


3

The only way to be secure without TLS is a browser plugin, which needs to be downloaded... over TLS. And a browser plugin is a huge usability drawback. The reason for this is there needs to be some trusted code on the user's computer. This can be either the TLS code in the user's browser, or the plugin code.


2

What is your threat model? If every connection is sent over SSL, you do not need to worry about anyone sniffing your communications. This is actually the strongest part of your system. Good job choosing something standard. Because SSL is ensuring nobody is listening in on your communications, we should look at the endpoints. Your UUID is basically a ...


2

both methods in the questions deal with 'with plaintext passwords', which is a very bad idea. Yet , for illustrative purposes is can help to clarify things. Comparison logic in application: $result = sql_query('SELECT users.password FROM users WHERE userId = %i', $userId); if ($result['password'] == $userPassword) { print 'access granted'; } else { ...


2

It's simple. Never trust the client. Never rely your business on storing any secrets in the client that the user are not supposed to know. It doesn't matter whether this is Android, desktop, or whatever. Unless you're prepared to secure your device like an ATM (bolted onto a wall in a weighted safe, and cameras all around), the client is not to trusted. ...


2

The additional overhead caused by the encrypting your payload is almost zero since CPUs today can encrypt at speeds of up to hundreds of MB/s. The only noticable delay is during connection setup, as you need a few additional round trips to set up SSL/TLS. However, if you are transferring large files, this round trip cost is negligible. Yes, caching of ...


2

Something else to consider is that the average permissible attempt rate (imposed by either throttling or lockout) should in theory be tied back to the effective cover time of the users' passwords. That is the throttling/lockout should be sufficient to prevent a brute-force attack via the web interface from being successful before the user next changes their ...


2

In fake authentication attack there are two types of WEP authentication (Open System and Shared Key) you can only do fake authentication for WEP enabled AP. This useful when you need an associated MAC address in various aireplay-ng for example in WEP cracking attack when there is no associated client. It should be noted that the fake authentication attack ...


2

No, asking for a password or secret answer via 3D Secure is "something you know" and not another category of authentication as the cardholder data (number, expiration date, code) could also be "something you know". To qualify for "something you have" it will need to be verified in real time. Applications such as Google Authenticator and 2FA dongles can work ...


1

If you're calling a foreign API (e.g. Twitter) for which your entire app has a single API key, you can either: Share your API key in your app -- a "not-secret secret". It's a crappy situation, and you can obfuscate the key somewhat. But if it's client-side then there's no protecting it. End of story. Keep your API key on your server and proxy API calls. ...


1

I see two possible attack vectors. eavesdropping cross site scripting vulnerabilities in your web application When the token isn't transmitted via HTTPS, it can be intercepted and used by an eavesdropper. To prevent this, enforce https for all communication. When the HTML document includes any data from a 3rd party, you need to be weary of XSS ...


1

The main difference is that an "account lockout" is based on user accounts and throttling login attempts can also be done by limiting attempts per client. Throttling login attempts per client helps for example if a single malicious client does not target a specific account but tries a different account name on every attempt (or until the account is locked). ...


1

It sounds to me like you need to configure the Tomcat service to request a client side certificate for authentication. I'm wise in the ways of IIS, but unfortunately Tomcat is not my forte. DO NOT give the admin of Tomcat your CSR. I recommend referencing Configure SSL Mutual (Two-way) Authentication Ideally you would use your internal CA to sign a ...


1

Throttling is used when lockout is not an option. This particularly happens when under an imperative need to avoid involving support operations (new startups with high user count), giving security more weight than business continuity, compliance or safety reasons (the lockout may endanger someone's safety).


1

The currently known methods of using "a public/private key pair" require too much communication; i.e., both ends would need Bluetooth or the token would need a computer-screen-reader or the process could get tedious. "a shared secret key" minimizes the amount of communication that is required.


1

However, the webservice for creating the account has no restrictions, meaning an attacker could spam GET requests to it from any device to create any number of users they want and flood the database/server. My question is, how can this be avoided? You can use a mix of CAPTCHA and IP restrictions to avoid such type of attack. IP restrictions: ...


1

Think about it this way: Most system have multiple components. In a traditional set up this is usually a client that is distributed to the users, a server, and a database. The database is usually a commonly used, highly optimized piece of software written by somebody else, whereas servers are very often custom software that is written by you specifically ...


1

Application The application supplies the credentials via the application code logic to the server as a payload of the application's data flow. Database The connection directly connects to the database and issues database commands in order to confirm the credentials.



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