Tag Info

Hot answers tagged

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


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


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

This question is extremely broad, but I'll point you towards some information that might help: The Definitive Guide to Web-Based Forms Authentication The OWASP Secure Coding Guidelines The OWASP Top 10 Project Some of our highest voted questions.


5

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


4

To understand this problem, first you have to understand why we hash passwords. It is completely possible to store a password in plain text on a server and simply compare the password transmitted to the password received. As long as the password is protected in transit, this is a secure means of authentication (shared secret). The reason that passwords ...


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

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

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


3

I find two possible flaws. UUIDs in general do not guarantee to be cryptographic random. Depending on implementation it may be possible to give a qualified guess about what other UUIDs have been generated by a generator, given some of the output. You need to use a suitable length of output from a cryptographic random number generator as session token. ...


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

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

What kind of application is this, and how does it get executed before logging in? Actually, scratch that, a better question would be: WHY is this application allowed to run. Yes, it is very dangerous. This allows arbitrary users to run any system command. The process account is known as LocalSystem, which is the only local account with more privileges ...


3

What advantages would client-sided password hashing have? Well, the password wouldn't be sent over the net in clear-text. But you should really be using TLS encryption when you log in, so password sniffing should not be an issue. Another reason could be that you don't want the server to ever be aware of the users password, not even for a microsecond. That ...


2

The best practices you should be concerned with here are: Don't re-use credentials for multiple purposes. The two servers should not be sharing a private key. Hobble automated processes. Make sure that the SSH channel that is being opened up by server2 is limited to only copying files, and only to the intended directory tree. The latter is important. ...


2

In addition to the other answers there is actually a way to grab domain admin credentials. One of the functions of Windows is to cache credentials for a while when opening a login. With Local/System rights you are actually able to extract these from memory (out of the LSASS process) using a tool like Mimikatz. The catch is that someone who has Domain ...


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

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

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

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

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


1

Since you are talking about web application... In a database we have a table call dbo.useracc we are storing these hashes password User Password -------- ---------- user1 5f4dcc3b5aa765d61d8327deb882cf99 user2 202cb962ac59075b964b07152d234b70 user3 098f6bcd4621d373cade4e832627b4f6 and our login function in web application ...


1

So long as your token is sufficiently long enough, I think you would be OK using simply SHA256. I'm not very familiar with PHP, but it looks like you are creating tokens of length 200, which would be more than sufficient. The reason that I would think that SHA256 would be OK is that the search space for a length token is so gigantic that it doesn't really ...


1

What you need is remote attestation (QUOTE operation). The Endorsement Key (EK) is not directly accessible as this would be privacy issue - we could track a system using this unique identifier. The EK can be used in conjunction with an Attestation Identity Key (AIK) or using Direct Anonymous Attestation (DAA). The AIK model make use of a Privacy CA ...


1

In addition, I would add that most attackers don't directly log in via the console or ssh, but instead use bugs in other software in order to break out into a root shell or elevate their privileges. Adding 2-factor authentication or other mechanisms will definitely improve your security posture, but must be viewed as part of a larger overall hardening ...


1

Great answers so far, but something that I think should also be mentioned because its not very clear from the article you referenced. The hashing function is run against the salt concatenated along with the password and then the salt is concatenated again with the resulting hash from the function and that string is what is stored in the password database ...


1

can't comment, but I agree with @Tom's answer, with a few points to add: SSL/TLS server authentication depends on the "strength" of the server key -- both its size, which you can see, and that it was sufficiently random, unlike for example the Debian openssl packages a few years ago that used a crippled RNG or the thousands of apparently unattended devices ...


1

Your Web browser will always try to authenticate the server's certificate; it will complain loudly when it cannot. The point about optional authentication is for the "DH_anon" cipher suites in which there is no authentication at all. Such cipher suites are, by definition, insecure against active attackers, and thus should not be used. Web browsers don't ...



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