New answers tagged

1

With all new browser recommendations and drafts it is really hard to tell. But in it's current state it is unlikely to be widely adopted anytime soon. For starters this is a draft. Not a standard. Nothing is finalized and subject to be changed or dropped altogether. This is the biggest reason vendors will not be rushing to implement it. The next step is to ...


0

Humans always want to transfer their responsibilities from their shoulders(Not everyone). Security is a great responsibility and most businesses want to focus on the core business and give their customers best of their product rather than worrying about the security. Single point of failure is definitely something to worry from a security perspective but ...


1

Trusted party is exactly that. Someone who is trusted when he identifies you. The most basic vouching happens when you go in front of the HelpDesk and tell them that you forgot your password and are now locked out of your account. Then the IT staff vouches that it's you and resets your password. Now suppose that no domain admin was available when you went ...


0

I would say because it allows a massive increase in potential damage if one account gets hacked. Say I want to get into account A. If account A set up account B, C, and D into vouching for them, I have 3 more potential targets I could try to weasel access from. One of them is bound to have a weak password or is susceptible to social engineering. Now that I ...


1

usually a user table provides the relational association to content in the actual database. eg user:jon_smith posted this blog post The user table is also the logical place to store login credentials. The problem/question is not 'why is a database storing login credentials', but rather 'why arent people storing hashed values of passwords and comparing the ...


0

JSON and OAuth are used in conjunction but are two different things. While JSON is a format for structuring data, OAuth is spec that allows users to share the private resources on one website with another site without sharing the credentials. OAuth has not been designed as authentication protocol but rather as a "delegated authorization protocol". It can be ...


0

So why do we even use full-power database software and SQL queries to handle the pretty limited needs of username & password authentication at all?. Why aren't there limited-purpose database applications specifically aimed at just doing what a password database needs to do, vs. using general-purpose applications that leave lots of room for SQL ...


1

Another angle to symcbean's answer. The whole situation seems rather simplified. Who should take care of what can be queried and what can't? The underliyng DB (using special tables for user storage), the backend of the web application server or even a WAF? What about queries including LIKE statements (i.e. PasswordHash like 'a%', you can see where this is ...


1

People who say that are confused. You need to not blindly trust data stored in cookies for important operations, but storing non-confidential (and the username is not confidential) information in a cookie for convenience is fine. Just don't use it for security decisions without validating it first. So, storing the username in a cookie to say "Welcome ...


1

It is a bad idea to generate the key for asymmetric cryptography totally on predictable data (i.e. user chosen password) instead of secure random data. By basing the key completely on predictable data the key gets the same predictability as the password used as input. Still, asymmetric cryptography can be used for authentication/login but not in the way you ...


1

In its plain form, CBC-MAC is vulnerable to "length extension attack", where you just add some blocks at the end. So in order to stop people from doing that, you need to somehow mark the final block as indeed the final block. And not treat it like any other block. Wikipedia lists two ways: either prefix with block count, or encrypt final block with ...


5

There's a big gap between "does not require" and "implemented by the lowest bidder". why do we even use full-power database software and SQL queries Because if you're already running a SQL database for your transactional data, implementing a second technology stack with appropriately trained development and support staff for a very specific function is ...


0

OAuth 2 client credentials grant is designed for communications between services. Authentication for client credentials grant typically involves passing a shared secret, instead of a login/password. The shared secret is used to meet the RFC requirement of a "confidential client" for client credentials grant. If you don't already have an authentication ...


1

I would say its secure. The unique link, ensures that nobody that know your birthdate, can just logon and gain access to your information. And the birthdate login, ensures that somebody that catches the email in transit (for example, on a public wifi), and the email happens not to be encrypted, cannot abuse your link since they don't know your birthdate. I ...


3

The security lies in that you have a unique "access token" per client. So you can revoke and control as you will. Look at for example, Googles "App Passwords" which are the same thing. These tokens, of course make the 2FA no longer 2FA, but thats required for software and programs that do not support 2FA at all. The idea is that if a token becomes ...


0

If you only want to read additional data from the token (like JWT), it is no security threat. Since this part of the token is not even encrypted. If you want to expose some secret keys by hardcoding them or getting them from a web server to change and create a new token, that might be a subject of XSS and so on for example.


3

A bit of a wild guess here: privacy and anonymity. Having worked on ePassport software, I can tell you that developers need to be extra careful when handling users' fingerprint and iris data. Think of how careful we are about storing usernames, passwords, credit card numbers, etc, then consider that in the case of a breach, passwords and credit card numbers ...


1

From Gray Hat Hacking The Ethical Hacker's Handbook, 4th Edition: Enumerating Named Pipes Named pipes are similar to shared sections in that developers used to think, incorrectly, that named pipes accept only trusted, well-formed data from users or programs running at the same privilege level as the program that has created the named pipe. ...


1

In your question you are only taking about keys, where a key can signed by someone else but the key is not associated with an identity itself: If John also has a key signed by Peter, presents it to Bob, Bob verifies, but John says that his username is Alice, than what to do? You then propose the concept of adding the identity: Is it ok if Peter ...


0

First, remember that Authy allows you to use any TOTP token (like Google authenticator), but they also offer their own proprietary 2FA method. In Authy's method, the account provider must integrate Authy into their authentication mechanism, not just implement the TOTP standard. In this method, Authy issues the seeds, and this also allows them to support push ...


0

The connection is unencrypted UDP (if you know how to properly encrypt UDP, than tell me) DTLS (Datagram Transport Layer Protocol). DTLS works very similarly to TLS, but is instead designed to be used in UDP and preserves UDP semantics (unordered, no automatic reordering/resend, low latency). DTLS is widely used to secure UDP, for example in ...


2

Google Authenticator worked for me - but it was a little bit tricky. Go to https://myaccount.google.com/security and start the process of enabling 2FA Google required me to enter my phone number - I could not find a way to enable Google Authentiactor without prior entry of a phone number. So do this and enable 2FA. Once 2FA is active, you can add a second ...


2

As @jpodwys says in his comment, HTTPS is a secure transit. It seems very unlikely to me that an attacker could steal an OAuth2 refresh token and not steal other critical information. That is, by the time you are having tokens stolen over HTTPS connections, you've already been pwned and it's game over. OAuth2 is a well-tested protocol that has many tested ...


0

Tokens are used to access APIs programmatically; passwords are used by users typing them in. Brute-forcing of passwords is prevented by strategies like splitting up the typing of username and password to two different pages, adding secondary input fields like captchas, and forcing a waiting period (or disabling the userid) after some number of unsuccessful ...


1

This is how normally you investigate this. If it is a hash of your password, then you could test your password with the hash function and compare the output. This particular (assumed) hash string has 232 hex-digits, which equals to 928 bits. This is the exact size of RSA-280 number, which is used in SHA-1 encryption (along with many other RSA numbers, so you ...


2

It allows to identify the password reset attempt Suppose that you request a password reset (new password: "12345"). However, the reset email is slow to come and, after waiting for some time you conclude if failed and make a second attempt (new password: "67890"). Meanwhile, the first email arrives. You open the password reset email and it tells you to ...


0

In the case of an application I recently wrote, the access token is a symmetrically-encrypted string of the form nonce=123456789;userid=123;username=bob;login_expires=12345679;... The encrypted string is the cookie and is quite long. Decrypting it is fast, and assuming no one stole the secret key from the server, the data is authentic.


0

It's conceivable that there exists an mobile app that one could log into with name/pass and that app will take the name/pass plus some unique identifier from the device to generate a code which can be entered into a website for authentication. I think the OP wants to know why the generated code would be necessary if the attacker already has the name/pass. ...


2

If you need to store relatively short passwords, there is a bunch of precautions you have to take: Salting with a unique long enough salt to prevent rainbow-table attacks. Key-stretching so the calculation needs some time, to hinder brute-forcing. On the other side, if the token is long enough you can store just a plain SHA-256 without any drawbacks on ...


10

There are several reasons for that. One reason is that memorable passwords are too short for the expected security level. Several methods are used to mitigate this problem, but it would be problematic to apply them to access tokens: Some services require a second authentication factor. Access tokens are meant to be used without user intervention, so most ...


18

Quite simply, the token is not designed to be memorized so it can be as long as they want. A password is limited in length to what a person can practically reliably recall after a short memorization period. This limits it to 7-10 characters for most people. The token is designed to be copy/pasted, just once even (since it is application specific) ...


3

2-factor authentication means to enter MOBILE app (using username and password) and then from that app you get codes to enter your account from a browser on a PC browser. No, no it doesn't. There are several kinds of 2FA. One is by getting a text message. You don't enter your site.com credentials on your phone to get a text message, you tell site.com ...


1

The major threat that mobile-based 2FA is designed to protect against is not a loss of your phone. It is against a network attack. It is very hard to imagine how an attacker at some random location on the planet can spoof your login to a website if you use mobile-based 2FA and they don't have your phone. They would need to physically get the phone. This is ...


33

There are two reasons to ask if your password is being encrypted: You are worried about the security of the site. You are worried about the security of your password. Regarding site security, with no HTTPS, there is effectively none. You should consider every communication with the site as public and assume that an attacker can pretend to be you. Just ...


20

What you got there is 232 hexadecimal digits, or 116 bytes of data. It is not a plain text string in any normal encoding. It could be a hash of your password, it could be your password encrypted, it could just be some kind of easily reversible obfuscation. Or it could be something completely different from your password, like a session identifier. It could ...


7

When you want to eavesdrop on the communication between your web browser and a server, you can often do that with the developer tools of your web browser (usual hotkey: F12). Most browsers will have some kind of Network tab where all network communication between the current website and the internet is logged in cleartext. When you find your cleartext ...


0

There're two possibilities, your password is either encoded or encrypted into that string. If it was encrypted, then it can only be decrypted using the key defined in the webapp, which is quite secure and need a long time to try breaking it.


7

2FA means to have to two factors for authentication, preferable one is a physical factor ("know" and "have"). The idea is that this way it is not enough to get the password due to hacking, data leakage, phishing etc but that the attacker must additionally have access to the physical device. There are lots of physical devices usable with 2FA like security ...


2

This is relatively old but we once tried to record my friend's voice and play it as an authentication for his voice detection mechanism. We were able to fool it only 1 time out of 5. Also, we made him speak the authenticating words again when he was talking to someone else and caused him to unlock the phone. The attacker was standing just next to him with ...


158

As you said, you saw this on facebook - so I tried these steps: Login with lukas@gmail.com and real password -> works Login with lukas@gmail.cmo and real password -> works, too (!) Login with luksa@gmail.com and real password -> also works Login with luksa@mail.com and real password -> also works Login with lukas@gmail.cmo and wrong password -> Wrong ...


12

Allowing username or email iteration may be a security problem for most sites, but not for Facebook. For sites as large as Facebook, finding emails that have accounts is easy because the sites have so many users. This holds for other huge user databases like Google and Microsoft. These companies just have to be secure in the face of their username/email ...


1

Based on the details you've provided here, I would say "Yes, that is a security risk" because it 100% identifies who is registered on the site. I don't know how many times a request can be submitted before a block is placed (CAPTCHA, IP-block, etc) but an attacker could simply "brute-force" a set of usernames and emails to obtain a pretty clear list of who ...


0

You don't really describe this step very well: If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database. Exactly how is that 128-bit key created? That should be a very ...


6

No, you're actively harming usability with no gain to security. This sounds like a bad case of Security Theater*! I say this because what you're currently doing is only just as secure as sending over the username and password over HTTPS anyways! All you add is a couple of extra setup communications. The vulnerabilities of this implementation as well as the ...


4

This is less secure than the normal way to set cookies because you can't set the HttpOnly flag on your cookies. This means that the cookies can be read by Javascript, and this is particularly a problem if the website has an XSS vulnerability. In that case, the attacker can directly read your cookies and take over your session.


0

You should add that: No passwords should be their user names (that is just stupid but happens). No actual words, or at least a word combination that is not in dictionaries (I learned from a website about cyberspace problems and one of them was about problems. It said that sometimes hackers attack and hack with computers that could find words and then ...


1

Of course it IS A SECURITY ISSUE. Read-only is safe - regardless of protocol : FTP, NFS or CIFS/SMB. But write/alter access does means a way greater responsibility: you need at least a stream-in antivirus, autorun names ban and many other restrictions. IP restrictions does not count : everything can be hacked, remember.


2

This sort of thing makes a lot more sense on a touchscreen of some kind, or a physical interface. I've seen pictures of PIN pads on doors that do similar shuffling using light-up numbers under each key instead of physically painted or molded lettering. I'm not in a position in my life where I've actually encountered that level of security outside of ...


5

This is to a large extent just security theater. It forces users to hop through a couple of hoops in the name of security, and thereby make them feel secure since they expended effort in the name of security. That said, it does in fact defeat a simple key logger (since no keys are pressed) or a mouse click logger (since knowing the coordinates of a mouse ...


3

Possibly, sometimes. What's exchanged in the initial handshake is not just a symmetric key, but rather a "master key" for the session from which the client and server implementations of the selected cipher suite can extract keys for various purposes. A cipher suite is split into a number of algorithms for different functionality: Key exhange Bulk ...



Top 50 recent answers are included