Hot answers tagged

16

Technically, only the target of the form needs to be a SSL protected page for the submission to be encrypted. I saw this done at a previous job where we had a login form in the header. HOWEVER By doing this you are losing the clarity that we've been telling users to look for. Users are instructed to look to the URL bar to see if the website is using an ...


15

A very good idea to avoid mass profile making without adding a captcha (let's admit it, even when you know they are for the good, captchas can be just annoying) is to make a hidden <input> element. You check if this element is filled up: then it usually means it was a bot: in this case you give the bot a false success message and just throw the data ...


15

Note: I'm not claiming this is how Facebook or Twitter does it, I'm merely providing a general-purpose way of accomplishing 'Logout on all devices'-functionality. Generally speaking, authentication works by sending a token to your device, that you subsequently use when making calls that requires authentication. Now assuming this is a valid token, the ...


14

There are several way how to implement authentication in RESTful context, and it is more safe to send only tokens instead of login/password: you could easy make tokens to be invalid by timeout or by some other criteria, and ask user to re-authenticate. For example authentication REST requests using HMAC. In this approach, client will have public and secret ...


13

No particular reason at all. It's as arbitrary as "your password may not be longer than 8 characters". It's programmers or product owners that don't know what they are doing. There can be some legacy reason for this, when the authentication system is linked to some credential system that has had certain limitations for historical reasons (something like a ...


10

Larry Osterman wrote about "Why is Control-Alt-Delete the secure attention sequence (SAS)?" back in 2005. The answer is so short that there is no real need to summarize it, although I am eliding a few side notes. When we were designing NT 3.1, ... we needed to have a keystroke sequence that couldn't be intercepted by any application. ... It turned ...


9

oAuth is the standard for this but there are more solutions. Don't try to implement security, tokens etc. all by yourself since that's a difficult and risky topic. Take for example a look here: https://stackoverflow.com/questions/4574868/securing-my-rest-api-with-oauth-while-still-allowing-authentication-via-third-pa


7

I think you should consider using an SMS or email verification method in addition to a CAPTCHA. You should also consider logging IP addresses who create accounts and if someone attempts to register another account with in a time window you should deny it or ask for further verification. Another approach you could take would be to have moderators and make ...


7

The immediate issue here is that a user's password can, and should change occasionally. By tying your unique ID to the password, you're effectively creating a new user account whenever a user changes his password. If possible, the unique identifier should be something that never changes. If you have some sort of set-in-stone ID such as an employee ID or ...


7

emails containing an encrypted personId in the query string of an https link Firstly, encryption isn't really what you want in this scenario - you really want entropy. Your login token should be entirely independent of your personId, instead it should be a random string generated using a cryptographically secure method. Of course you will need to store ...


6

Pretty much every website I know does the same. Account security relies on password, not the user name. This password should be kept secret and secure. If it is, it doesn't matter who knows the user names. If it doesn't, deal with it, because it's the primary issue: hiding user names won't help. Note that relying on the fact that the web application doesn'...


6

Why it cannot be intercepted: Because it would be a huge security risk. Imagine an application which launches at logon. It shows a false logon screen to the user and invites the user to enter a password. To avoid this scenario, you often have (in business environments or on Windows Server) to press Ctrl+Alt+Delete before logging in; this ensures that you're ...


6

I recommend keeping your RESTful interface stateless. This means for every request, you must pass in all authentication information. I have used Basic Authentication (credential in HTTP headers) with great success. Keeping your RESTful interface stateless greatly simplifies your server logic and your client's logic. Every request is autonomous, and you ...


6

It's certainly safer than using a cookie when it comes to CSRF, but it is less safe when it comes to XSS, because session storage can be read from javascript, while http-only cookies cannot. So it depends on how confident you are about your protection against XSS. If you do go for this approach, I would suggest using the Authorization header with the ...


5

Amazon (and many others) use a hybrid approach. They provide autologin for browsing, adding items to the cart, and placing orders using credit cared/shipping address combinations you have used before. However, they require you to enter your password for many actions such as adding credit cards, adding/changing shipping addresses, updating passwords, ...


5

In a comment to another answer you said the answer explained why it shouldn't be intercepted, but you are asking why it can't, not why it shouldn't be intercepted. Maybe I'm pointing out the obvious, but it can't be intercepted simply because that's how windows was designed. The OS obviously intercepts it, and it simply refuses to pass that event on to ...


5

Short Answer: Start with analyzing generated HTML and solid fundamentals of HTML knowledge. It is always a BIG back draw to rely on generated code without analyzing and understanding from where this magic comes from. You may end-up with hours of maintainability issues if you push such code to the production. In another words, know your code and its ...


5

Every session is going to have some authorization artifact it uses to track sessions. (In web applications, usually this is a token in a cookie, although it doesn't have to be in a cookie.) When your application grants those authorization artifacts, you can keep a link back to a user, and then manage them as a one-to-many relationship -- one user has many ...


5

If the requirements tell me to store what appears to be duplicate information, then I would store it as such in my object and/or database. However, unless the requirements also say that I must collect the email address twice (once as user name and separately as part of the contact information), I would ask the user only once and internally copy the ...


5

To answer your question, you might want to consider not 'coding' them in, especially if you are using a compiled language. If you do, rotating passwords is much harder. You will also need to consider things like: Where you store the passwords, if in a file make sure it is not browsable Make sure robots cant find your login (or post-login) pages Make sure ...


4

You can use OpenID for this as long as you request the user's email address and confirm it's that of a family member. So you're backend or settings code should have a list of family email addresses. Anyone else authenticating over OpenID could immediately be booted by your web application. Think of the OpenID as an identifier for the user. The choice to ...


4

What StackExchange seems to do (I haven't seen the database schema) is to separate the notions of user account and login/authentication. You can have (and I do) multiple authentication methods linked to the same account: Once you are logged in, you have the option to add other methods. I would implement that by having a table for authentication accounts ...


4

It would work. But it would be pretty aggravating to anyone who has graylisting set up on their mail server, which would delay your email for 15+ minutes. And certainly you wouldnt want to be sending an unencrypted login link for a site that has any e-commerce purpose or stores personal information. A better approach for you may be to use Social Login, ...


4

You should make them enter the whole thing in one step, and you should make the format explicit. Phone numbers are very tricky, especially on a global site. You should take every step you can to avoid ambiguity, guesswork, and fancy country-based magic. If you truly need to use phone number for "login" a single form can work better with "remember my ...


4

Hashing A hashing function uses an algorithm that is created with several things in mind: Any hash generated will have the same length (i.e. a SHA256 hash will always be 256 bits) Using the same hashing algorithm with the same input will always give the same output A tiny change in the original value to be hashed will have a huge impact on the hashed ...


4

As written, your requirements seem clear: there is a separate field for a user name, and a separate field for the e-mail address. This being said, you may need to discuss the requirements with the person who have written them in the first place: It may appear that, indeed, there is a clear separation required between the contact info and the authentication ...


4

The usual approach is for the authentication service to issue the user a signed token. Other services can verify the signature to check that the token is genuine. The token then contains the user ID. Don't roll your own, but use an existing approach like JWT instead. Be aware of the drawbacks: tokens cannot be revoked individually. A token is valid until it ...


4

Login should always be processed by a server side code. One of the example is php. The php part would retrieve the username and password and query with the database and check if the pair exist. You need to learn some server side language. It can be any language like php, java, python or nodejs. As you already have knowledge of javascript, you can go with ...


4

What's stopping a determined individual from creating their own XML file with their own details, encrypting it with their own key, and placing it on the computer via USB drive? Before you consider what is (not) stopping them, first ask yourself why they would want to do it to begin with. What do they have to gain by getting a succesful login? Because if ...


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