Tag Info

New answers tagged

0

There are a couple of potential risks here, depending on how exactly this is setup and what the requirements are. If end users can obtain direct access to layer red and can obtain valid credentials, they then have unfettered access to layer red using only those credentials, skipping the auth check on layer blue completely. If layer blue only exists as ...


1

This is more a solution to what I'm trying to accomplish than an answer to the question I asked. If somebody has a more direct answer to the question asked, please contribute it. Thanks to the good people at CERN and Ubuntu for getting me on the right track: http://linux.web.cern.ch/linux/docs/account-mgmt.shtml ...


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


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


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


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


0

There are some misconceptions or half-truth about HTTPS: Performance: If you have lots of short connections it will be much slower because the main costs are in the initial key exchange and in the additional round-trips needed to establish the SSL connection on top of the TCP connection. The encryption itself is cheap, that is the more you transfer over ...


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


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


0

It does stop the most rudimentary bots which repeatedly POST the same form. As you have mentioned, a more sophisticated bot can evaluate the result and append the unique nonce to every request, thus defeating this system.The most sophisticated bots can even go one step further by performing optical character recognition(OCR) on captcha images and input the ...


0

Short answer, simple match in clear text is not a CAPTCHA. Read the CAPTCHA wiki to get a better understanding of what defines a CAPTCHA. CAPTCHA Characteristics: CAPTCHAs are by definition fully automated, requiring little human maintenance or intervention to administer. This has obvious benefits in cost and reliability. By definition, the ...


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


0

This is Security through obscurity and it appears to be being used as a measure in lieu of properly securing the customer portal. There is an advantage of never sending links in emails though, as this could reduce phishing attacks on your customers. However, customers must already know that you never send links via email as an attacker sending a phishing ...


0

There are several attack vectors here if someone wanted to pirate this software. They could modify the binary or replace the remote server with a fake one. In general, DotNET binaries can easily be disassembled or decompiled back to readable source code, for free, see http://www.jetbrains.com/decompiler/. Even worse, the code can also be edited and ...


0

Your scheme is vulnerable to replay attack: an attacker can manipulate the time and date setting of the local system in order to fool your app into accepting an expired security token. Furthermore, since you're placing all security element inside your local storage, you simply cannot protect it against the local user: he could, for instance, run your app in ...


0

You're right: missing TLS is a far greater problem than just modifying the login form's action. Have a look at the full paragraph from the link you provided: The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to ...


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


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


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


0

Unless you are sending specific strings in the URL to provide pass-throughs (where a user can click to log in without authenticating) there is no more danger with out without links. The reasoning for this is, someone can stumble unto your portal as it stands (provided it is on the public Internet which it would have to be unless you established some form of ...


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


0

The MySQL SO_PEERCRED authentication is fairly recent, it was added in version 5.5.10, March 2011. The similar Postgres authentication is a lot older. (Note that Postgres also supports ident, RFC 1413, authentication; MySQL does not, that would be another plugin, perhaps someone will write it.) The relative newness of the feature in MySQL would be one reason ...


0

Path of least resistance. Shared secrets are easier to use, which means easier to write implementations against. Public key systems are significantly more difficult to write implementations against, therefore fewer people will do it. There are asymmetric key-based protocols out there that do offer more/different protections and change the security ...


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

However, it's not login-based in the traditional sense that users don't sign up with an email or anything. We just automatically create an account for them with some randomly generated UUID as their "login" to the service. If you are just allowing ANY user to create an account with your application, without providing any personal information, it ...


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


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


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


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


0

How can they enforce that? The browser plugin will not store the data permanently on your local machine if Permit Offline Access is set to Disallow. It is only available while your internet connection is active and your session with LastPass is current. If they somehow encrypt my password db with a key returned by the google authentication procedure ...


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


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


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.


1

Yes, hashes can be used in conjunction with a shared key to authenticate a message (this kind of Hash-based Message Authentication Code is the HMAC often referred to in cryptographic protocols). Some details are here. This also provides message authentication (in your scheme, Mallory could modify T2 and Bob wouldn't know; that can't happen so easily with ...


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.


1

Pros: You could gain security by having that the physical access card, that is used to open doors in organization, must be placed on a Reading pad or inserted in a smart card reader, and kept there to keep the computer logged in. As soon as the card is removed, computer is forcefully logged out. (shutdown /l /f /t 0) I would advise against locking the ...


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


0

If you mean "trust" in the communications sense, you're defending against man-in-the-middle attacks, and that means using HTTPS. For bonus trust, use certificate pinning in the mobile app. If you mean "trust" in the "server wants to ensure that the client has authenticated" sense, you should read more about OAuth. The short of it is that Your user will ...


1

The other answers are clear - use SSL however, to point out what would fail if you implemented it as described: I thought of solving it with a first hashing on client side with JavaScript and then on the server side, if I receive hashed values(in case someone deletes some JavaScript), a second hashing and store those hashed values in the user ...


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


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


1

Stringify the sent information in a standard way, take the SHA256 hash, sign it with the private half of the key-pair that is genned for the handset when the application is installed (the public half is sent to the server at enrollment time). Most importantly, HMAC is easy to do wrong because it is crypto and crypto is really hard to do right (even Ron ...


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.


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


0

A strong authentication mechanism that is easy for the user and provides reasonable assurance would be to stand up a CA that is not trusted by anyone other than your application. Issue each user a certificate with their UPN as the only entry in the SAN extension. Configure your application to authenticate the user via their certificate, and instruct each ...


2

It would not take away any security. Simple, Easy enter pins would simply auto-OK or auto-ENTER when 4 digits have been entered - just like iPhone. However, it would still mean that incorrect attempts are counted and at too many attempts the device is locked and require online authentication via google account. The implications "Easy Enter" could have, is ...



Top 50 recent answers are included