Tag Info

New answers tagged

2

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


0

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


4

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


1

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


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


0

I could well be wrong, but I suspect that this is just camouflage for some other process that is slow. Setting up an SSL connection - as you note - is usually very fast. For example, TurboTax does exactly what you describe, but I really think that they are just putting up something feasible for the general public when they are performing the authentication ...


0

The "OT" in "HOTP" means "one-time". This is true only if the server indeed rejects passwords corresponding to a counter value which is not greater than the last confirmed value. Having "a little margin" here would mean accepting that a given password is accepted twice, the very thing that HOTP tries to prevent. This is all based on the idea that the HOTP ...


0

Are you developing this software? I would just generate a unique token stored in database such as: TokenId UserId (Or some entity which this token relates to.) TokenKey (Which will be used as an identify to the public.) IsExpired Ip (Which is hashed such as SHA512 so doesn't expose the users IP if compromised.) CreatedOn UsedOn Now, we need reduce ...


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


0

What if instead you sent them a generic link that takes them to a page on your site which then generates a random, temporary url for them and forwards them to the registration page.


1

I don't think you can. You know nothing about the intended recepient, so whomever receives and uses the link is as likely as anyone else to be the right guy. A common half-measure is to make the link valid only for a short time.


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


-2

There is a security flaw with the Picture Password. After switching your login method to Picture Password, Windows 8 will then store your Picture password as well as your regular user password using the reversible encryption algorithms. Using the freeware Mimikatz and you can decrypt the Picture Password in no time.


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


1

How should I authenticate WebSocket clients like Socket.io on top of HTTPS ? There is no need to authenticate a connection more than once, so if you are using websockets, you can put security token in the first message that client sends after connecting to the service. HTTPS is a must. After handshake you will have secure connection (token can be ...


0

A simple Google search on "django client certificate" reveals this, and this, and this, which all answer to your question as: yes, Django can work with certificate-based client authentication. People don't do that often in practice, because client certificates work only if you can arrange for clients to have certificates, basically meaning that you must ...


1

Also see How safe are password managers like LastPass?. I had concerns about its security integrity and the fact that your passwords are saved on servers that are located in the USA. Even though they only store encrypted data, LastPass is obliged to give this data to the USA government when requested. Since I realized this, I moved to KeePass Password ...


0

http://en.wikipedia.org/wiki/OAuth http://en.wikipedia.org/wiki/OpenID Apparently answers need to be at least 30 characters, and that link wasn't enough


6

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


0

The sms vulnerability reported to Facebook was something else as far as I saw, it uses the Facebook's response to unregistered numbers to receive an unused confirmation code to reset password of other users... If you are using an Android device, I strongly suggest you should check your mobile for any malicious applications. While I was doing some research ...


0

I do not see any security issue in asking for the password and a second factor (token/biometric) at the same time. In fact this increases the security of the system, but it might affect the usability (user experience) of the system. How is that? Let us say that the system take the two-authentication factors (password and OTP) at the same point and test ...


0

"A login form could detect a username that has 2-factor authentication enabled" - How? In order to do this, the page would either need to send another request to the server, including the user name (which seems to be what you're trying to avoid), or the page would have to include a list of all the usernames with 2-factor authentication enabled in the body ...


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


1

There could be a number of non-technical reasons, possibly a driver would be performance because it reduces load to some processing on the backend that doesn't need to get called. Another possibility may be to make it harder to setup a phishing website. You now need to program multiple pages. Also, if you only show OTP when there is a successful ...


-1

For internet banking 2FA, this is the reason I could think of why they make a 2nd form. They want to reduce the load on the database and processing for performance issue. For internet banking our 2nd factor is normally a generated key with some devices and the key is normally changed every minute / X minute. Imagine on the server they need to re-generate ...


1

No, LastPass does not receive your login credentials. It looks like that statement is true. On their website, they supply JavaScript code to do in-browser decryption. So, yes, we still need to trust LastPass that this code is implemented correctly, but the password isn't sent to their servers. Resources: Lastpass Technology Lastpass How-It-Works ...


0

To store the token: For a traditional (non-Ajax) web app you usually store the token in a hidden form field. For a single page app you usually store the token in a JavaScript variable and include it in the JSON data with each request. This approach avoids the token being in the URL, and it works with WebSockets. Most applications use a cookie as the ...


1

One thing that some websites, like Google, seem to be doing to prevent this type of attack is to, after a certain amount of login attempts, not lock you out, but give you something called a CAPTCHA. This is used more to prevent bot logins, but it slows a malicious human user down, as well, as he/she still has to figure out the password, and some CAPTCHAs are ...


1

There is one key advantage to an assigned username or password - usually it's more random than a user would generate. For an 8 character numeric only username, there are 100 million (10^8) possible permutations. This is less than 1/3 of the population of the USA, and about 1/2 the population of Indonesia. So this method certainly would not scale to beyond ...


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


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


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


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


0

Burp can execute statistical analysis on tokens with the Sequencer tool. Send requests that return a security token from other Burp Suite tools to test in Burp Sequencer. Reissue the same request repeatedly, to generate a large sample of tokens for statistical analysis. Perform a rigorous set of tests, including the standard FIPS tests and others, ...


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


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


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


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

Yes, with AppArmor it might be possible: I have tried arround somewhat with using MAC (mandatory access control) and the AppArmor LSM (linux security module) and I found, that you might have a change using AppArmor to make /etc/ssh/sshd_config impossible to be written to using sudo. This AppArmor profile would limit what the user can do after having ...


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


0

This is called two-factor authentication. It already exists, though it may not be trivial to implement in all cases.


0

The security of this depends on how exactly you do the encryption. If you are using CBC-mode and no integrity checking, then I see a weakness that could allow one user of your app to impersonate another user: The attacker gets legitimately issued a token for their own Facebook account. They then wait 48 hours so the token is invalid. If they present this ...


0

Check out the OWASP website. The number two in the top ten is broken authentication and session management. Under this heading you will find examples that will answer this question.


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


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


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


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



Top 50 recent answers are included