Tag Info

Hot answers tagged

21

Adding logins means adding alternative methods to access your account; see this page for details. Thus, additional logins cannot reduce the risk of hostile hijack; in fact, they can only increase the risk since they provide additional entry routes for the attacker. If you have several logins, then your "security level", formally, is no more than that ...


14

Yes, this is insecure as specified. Your design seems to be vulnerable to Cross-Site Request Forgery (CSRF also known as XSRF) attacks (need to add a CSRF token with all POST actions that is displayed with the form and stored in a session cookie). Basically, if a user goes to some other website (email, forum, blog) while logged into your website, their ...


11

What you present is not an authentication protocol; it is merely a concept, namely the concept of a session token. In plain words: Server authenticates client, and send back a secret key to that client (the session token). When the client comes back, it shows the token to the server to prove that it is the same client as previously. The client can request ...


9

When you hash the password the first time (when the user registers), you use a salt and store both the salt and the resulting hash in the database. The second time (when they try to log in again), you use your username to pull the salt and the hash out of the database. You use the salt to hash their password input, and compare the two hashes. You may be ...


7

I disagree with Mark. A main goal of SSL/TLS is the protection of the long term key (i.e. the private certificate). If an attacker can obtain the key, the implementation must be considered broken. It does not matter if you use two-factor authentication or not. If I know the server's secret key, I can decrypt your traffic either directly (without PFS) or via ...


7

If someone compromises your StackExchange account can't they just unlink all your recovery options? Assuming they can't, the model is that: Losing any of the accounts linked to SE is a "compromise". If any of the other accounts linked to SE is not lost then you can "recover". On this model, 2 seems reasonable by your own analysis: 0 is no good, you ...


6

Banks that issue numeric usernames are rather annoying. And while I am more paranoid that most, you're probably right that someone just fat fingered their ID and didn't realize it until they locked you out. To answer the question, some banks do help ensure you are attempting to login with the correct user account. Those "Security Images" you see on some ...


6

You should ensure that you have the right skill set before offering to perform work for a client. This means that you looking at the website will be worthwhile and you won't give the client a false sense of security. This will be better for you as you will know how to take the correct steps to perform a test legally and won't get sued by the client if you ...


5

They prevented an attack on your account. This is a desired outcome - had they been able to try unlimited passwords, they'd have guessed yours. The attack was stopped in time, costing you a minor inconvenience. If this pattern was repeated in order to seriously inconvenience you, the bank can simply issue you a new random passcode. They aren't as ...


5

Proper two-factor authentication (authentication with both a password and a single-use token sent via an external channel) provides protection against the Heartbleed attack. An attacker can get both the password and the token, but with a proper implementation, the token is worthless for actually attempting a login of their own: it's single-use, and it ...


4

You could generate the passcode by taking a consecutive number and append one or more additional digits to it which are a checksum of the actual number. You can check the validity of a passcode on the client-side by checking if the checksum-digits entered by the user match the actual part of the passcode. One checksum-digit reduces the chance to ...


4

Security Theatre This splash screen is not necessary for the user, but the company chose to introduce a the splash screen showing that they think security is important and saying that they are supposedly away 'doing' security. The only good thing here is that they think security is important to them and their clients. The increased security (ssl/https) ...


4

The browser fingerprint is public information for any site the user visits, so this information should be treated simply as a 'username' and nothing more. The problem here is if the user changes computers, browsers, or settings they may be locked out of their account. There may be ways around this, but then you veer from your path of simplicity. The other ...


3

The salt is stored with the hash, for example in a separate database field or it is tagged onto the end of the hash or the username is used as the salt. The purpose is so that even if two users have the same password, their salts will be different and therefor their hashes will not be the same. This is useful if someone manages to steal the database, they ...


3

No With current technology there is no 100% secure way to transfer data over the Internet. The best you can hope for is to follow standard best practice. In which case you need to: Secure your web server - apply patches, hardened config, firewall Secure your application - code to the OWASP top 10, avoid SQL injection, etc. Use SSL to protect data in ...


3

First, CSRF protection is not a part of the problem or solution here, you're just overloading the term to be synonymous with session. As I pointed out in my comment, CSRF protection is primarily to protect against an attacker performing an action on behalf of an authenticated victim. Account creation (in most cases) is an action performed by an ...


3

Simply put, additional logins would have 2 effects: It increases the risk of attacks and account compromission but on the other hand, It lowers the impact of a successful attack by limiting the perimeter of data accessed. Then it's up to you to decide based on the risk you accept, and the balance you want in terms of usability versus security.


3

As usual, the problem is one of definition. Namely, what makes the device 'D' more "genuine" than a PC run by some ill-intentioned individual ? If you get down to it, you will say something like: device D is genuine because that's the true piece of tangible hardware, the accumulation of atoms which came out from the factory. This is fine as far as definition ...


2

Shared accounts are themselves a bad practice, because you cannot know who is actually doing the access. Each "administrator" should have his own account, to which you would grant administrator privileges. 2FA is about using two authentication methods concurrently, working over two distinct categories. The categories are: "something you know", "something ...


2

If you do not have access to the source code, you will have to make multiple attempts to see if there are any patterns in the token generation. If it is a basic incrementor, this may be easy to defeat. You can take the length of the token into account as well. Here are some OWASP guides on the topic, which may be of use: Testing for weak password change ...


2

There is an informational RFC for use of OpenPGP keys in SSL/TLS; as the RFC says: The term "OpenPGP key" is used in this document as in the OpenPGP specification [RFC4880]. We use the term "OpenPGP certificate" to refer to OpenPGP keys that are enabled for authentication. That's what these keys are for: usages as part of authentication protocols which ...


2

Web services can take into account the location of where log in requests are originating from and correlate with your past log in attempts. Similar to how credit card companies will contact you when they notice "unusual activity" on your credit card. This is one piece of logic a organization providing a service on the web can use to address incidents like ...


2

The user always submits the actual password to the server and the server stores the salt and hash values. The point of a salt is simply to make sure that if the DB is compromised, an attacker can't try brute forcing all the passwords at once. It also prevents identifying reused passwords. It doesn't matter if the salt becomes public knowledge because it ...


2

For this your main concern is making sure that the information is only accessible to the intended recipient; which sounds a lot like what public cryptography / PGP tries to achieve. Unless you want to see if the target non-user has a PGP key published, or if you can get his certificate to encrypt the email with his public key; I think you'd just need to ...


2

As others have noted, a big part of the role of the splash screen is to make sure that the user sees the word "securely" and gets the impression that "something is done about security". The best security systems are invisible (when you don't see anything, and business proceeds unimpeded, then the security systems are optimal), but the general public does not ...


2

The funny thing about providing a generic 'gist' of an authentication flow is that unless you really screw up the flow, you likely won't find serious issues because there just isn't enough detail to say one way or another. More often than not, its the implementation that is flawed. This is further complicated by the fact that you don't specify what you're ...


2

The difference is : OAuth 2.0 is a standardized protocol, and there is many implementations in differents langages (JAVA, Python, PHP, JavaScript...etc) for both client and server sides. So you don't need to follow this article to implement something which "seems" similar to the OAuth 2.0 protocol and probably not secured. For the cookie-based token ...


2

It looks like you're performing an "online" attack, in which case the speed at which you can work is limited by how fast your target computer is willing to respond to login attempts. Since your code isn't (or at least, shouldn't be) the limiting factor, there's nothing you can do to speed up the attack. If you can acquire the password hashes, you can ...


2

PuTTY does not store its configuration in a file. However, PuTTY can use a "proxy command", as described here. In your case, the example config file shows that there should be two encapsulated SSH connections: The outer SSH is done to host login.nets.***. When that connection is done, the command nc is run on that host: it basically forwards data bytes to ...


1

Let C be the attacker. C runs another server, under its own name (C), with its own public key Kc. Occasionally, A connects to C (knowingly, but not knowing that C is Evil, or believing that the evilness of C won't extend beyond C itself). Attack goes thus: Client A connects to C and sends {Kac}Kc to C. Immediately, C connects to server B and claims to be ...



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