Tag Info

New answers tagged

0

telegram probably will use features that are built in a mobile phone operating system to keep those cryptographic keys, for example Android key Store or Apple's Keychain. these key store mechanism will in turn utilising the hardware provided by mobile phone to prevent key extraction.


2

Actually, there is an often unused (at least on the web) optional part of SSL/TLS that allows for client authentication. It is generally not used on the web because the server doesn't really care if the client is who they say they are - they just need to have the proper credentials. Additionally, imagine the nightmare of having to verify every client in the ...


1

Any mechanism you come up with, that does not involve the user entering a secret for every request will be vulnerable to XSS. The solution is to try and eliminate XSS from your domain, not to have a solution that is secure in the presence of XSS vulnerabilities. A strong CSP policy will help you in browsers that support it. Javascript can access ...


0

Instead of using a hardcoded key, you should use mutual SSL authentication. Using an obfuscated key, doesn't add any security, certainly not when you're already using SSL.


3

A JWT token consists of a base64 encoded string containing header, claims and signature. The claims section contains a JSON encoded expiration field, exp: Expiration time. It contains the UTC Unix time after which you should no longer accept this token. It should be after the issued-at time. The username can also be stored in the claims object. ...


2

The difference between the two keys is that the Master key (PMK) is supposed to be valid for at least as long as the client is connected. In the case of WPA-PSK, the PMK is the same from the moment the AP is configured until either the passphrase or the SSID changes. Therefore, if the PMK is compromised in any way, the attacker gains "permanent" access to ...


1

Here's a little drawing: And the study that support it.


2

I am trying a different approach that doesn't require creating and managing passwords: I set up key-based authentication with the user's public key, disabled password-based authenticon for ssh and set up the user accounts with an empty but expired password (passwd -de). That way users get prompted on their first login and can choose their own passwords. I ...


0

Comodo, which was involved in this fiasco, trusts the following email addresses for domain verification: admin@ administrator@ postmaster@ hostmaster@ webmaster@


3

Edit: I realise that this may not be clear from the answer below... but from the point of view of your application, it doesn't really make any difference whether you run the PKI/CA yourself or whether you use one or more third-party CAs. Even if you choose to run your own PKI, you really don't want to code it yourself - so you'd use one of the existing ones, ...


0

Two factor authentication is requiring 2 out of three factors of authentication from either: 1. Something you know 2. Something you have 3. Something you are (biometric) Two factor is not a silver bullet though, as was mentioned because a factor can still be weak. The risk of having a weak 'something you know' is partially mitigated if you still have to ...


1

Both the goal and the approach are rather questionable. Users don't have HSMs in their PC (unless you're all working at a very special company which somehow provides its employees with crypto hardware). At best, you'll encounter a user with a smartcard, but even then they probably won't use the card for your site, because it's just too cumbersome. A more ...


0

StartSSL provides free Class 1 Web server certificates (SSL/TLS) & Client and mail certificates (S/MIME). I use them for both my website and email. Verification is done automatically and your clients would often get the certificates almost instantly. This is better than you operating a PKI and issuing the certificates yourself. You can check the client ...


1

If they cannot understand that the scenario is faulty, it might be better to side-step the 2FA argument and simply stick with the much simpler argument that having any factor that is insecure makes it a null method. In this case, unless you can enforce a strong PIN or passcode when creating the certificate, you can be certain that lazy people (most of us ...


0

Is this really a good idea? Yes, it could work, but... In case of a simple MITM attack, what will happen? Your server won't recognize hacker's client cert and will return to login page. The user will naturally re-enter his credential and so could work normally again. But from there, your server will accept hacker's cert, as long client don't try to ...


17

It is a bit of a fetish. As far as we currently know, there is no reason to believe that using the first four bytes of the HMAC output would not be equally secure. However, lack of reason to believe does not imply that nobody believes. Some people "feel" that systematic truncation may help the attacker in some completely unspecified way. With a lot of ...


1

The reason AES-CBC isn't an authenticated mode has everything to do with the CBC and nothing to do with the AES. CAST5-CBC isn't inherently authenticated either; changing one bit in the IV changes the corresponding bit in the first block, and there's no way to detect it, because that's a result of the CBC construction and not of the cipher.


2

Well in answer to your question as to whether there's a better way to do this, I'm wondering if a slightly simpler solution which I've used previously might be up to the task. Rather than generating a pre-defined list of challenges and transmitting them, have the client and server each add a predictable incremental value to the hash you pass in the header. ...


0

In practice, the ability to respond to email sent to any email address proves nothing at all, not even that you own the email address in question. All email is subject to tampering by the people who actually control the mail servers it passes through. If I have root access to domain foo.com, I have absolute control over all the email delivered there or ...


1

No. I'm not even talking about whether it's good enough for finance or not, I'm just saying if Google is the only way to login to your service, then I won't use it, and neither will do other privacy-conscious users. Now, on the technical side. Using third-party logins is less secure because a failure on the third-party site will also affect yours, and the ...


2

Password reset mechanisms typically work like this: The server generates a secret random string (e. g. 16 bytes read from /dev/urandom). Then the server sends this string to the user, often embedded within a link to a password reset page. A hash of the string is stored in the database for later validation. Usually, the string is only valid within a certain ...


7

It's a rather short list: ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ Now that's the fixed and static list. But: contact info from WHOIS is also legal. From the CAB-Forums' Baseline requirements, page 17: 11.1.1 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL ...


1

Generally, the very nature of PKI (and some good system maintenance) should prevent this from being a security risk. But personally, I'm not sure I'd really want just any website to be able to enumerate my Trusted Root CA list. This sounds like a good way to phish out systems vulnerable to attacks using stuff like DigiNotar certs or certificates from other ...


2

I work for a penetration testing company that requires a client certificate to log into any of our testing hosts. The certificates do require you enter a pass phrase when authenticating. This is done as an added layer of security, not to replace the need for passwords. If the certificate does not require a pass phrase, then yes - letting someone get a ...


0

Edit: Could I use JavaScript to send a GET or POST request to the server, providing a certificate that the CA I'm checking for has to sign? If the connection fails I'll know that the root CA isn't installed on the client. That's probably the best thing you could do. You still can get false negatives if the TLS handshake fails for some other reason ...


0

your Command aireplay-ng -0 0 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 mon0 is commrect. the -0 set the tool to send de-auth frames. the 0 after -0 means sends non-stop de-auth frames untill canceled with control + c. so if you have set the correct access point mac with the -a option and the correct Station ( STA ) Mac address witht the -c option, i hope ...


1

No, the web server cannot check to see all the CA's the client has installed. If you have access to the client machine, you can check by viewing the Trusted Root Certification Authorities store.


1

Why is the SSH authorization considered better? I mean if somebody gets access to my linux machine, then they can read both username/password OR the SSH key and they can then copy these information to their own laptop. Yes, true, if someone gains full access to your machine, you are in trouble either way. Am I missing something here? Yes. ...


6

There are several differences. First, by setting up your API server to accept username/password (as opposed to only allowing access via keys, which is increasingly a best practice to do) you potentially decrease its security in general, as, now, users with weak passwords on the system (or, worse, services that you install which may have hardcoded default ...


1

Well, if you drop the idea for username/password (that is not secure at all for this use) you could implement a chrooted environment for the ssh-client to connect into. using ECDSA or RSA Public key encryption, (you ship the private key with the app, and store the authorized keys outside of the chroot). Especially if you make a "dropbox" for the clients to ...


0

Remember in web 0.99, the idea was to maintain a certain amount of control over access to resources. So you, as the middleware developer, would get a user+password combination that would uniquely identify your requests over many different transport schemes ( the internet is not just www ). The idea extended to not just the act of logging in, the data itself ...


5

"Back in the day" we didn't really have any standards prior to oauth, everything was hand rolled and custom. (so for example the photobucket API provided its own direct authentication mechanism. ) Usually token based authentication with a API key (or even plain credentials. ) Back then the majority of online services were 'islands' of their own and didnt ...


5

There are several techniques that are still being used beside OAuth. API keys/Service keys Whitelisting IP's User/Password Login Token Login (non OAuth)... eg. custom implementation. none, just a 'secret' web-endpoint. and often a combination of them. What you saw often was a combination of whitelisting and one of the other techniques. OAuth was ...


0

The server will indeed have and announce to the client (during SSL handshake) a list of trusted client CA, and the client will have to provide a client certificate signed by a CA on that list. you said: In this way Server may be loaded with various Client Certificates? I guess you meant "Client CA". The server wouldn't be pre-loaded with the actual client ...


1

This a very good question. It is not difficult to imagine people making mistakes when logging into their account in a hurry, ocassionally missing a Tab and ended up typing (or worse submitting) their entire password on the username field. It is important to understand that the objective for password masking is to prevent shoulder surfing. It doesn't prevent ...


1

Theoretically, the professor should have disconnected the computer from the projector during the class. Any number of things can go wrong when typing a password that should be encoded in front of a class of students. It would give the impression that the username needed to be kept secret and would make users think that the username was highly protected by ...


0

In my idea captcha in login page is unnecessary and just bothering users you can use captcha after several attempts you can avoid attacker by using token and as I said captcha after several failing attempt. Use captcha in sign up page and use token in every form that you have in your web site.


2

Yes its neccessary. A token can still be requested by a bruteforcer. Yes, it would cost the bruteforcer one request extra per try, but a captcha still blocks attempts completely instead. If you dont want to bother your users with a captcha, you could set so when a incorrect password is used, the account in question will require a captcha. This both thwarth ...


2

Assuming AES is being used in any mode other than ECB, the IV is used in the AES encryption (the actual encryption is E_{Ks,IV}(F), not just E_{Ks}(F)). Every mode of operation for AES that I'm aware of except for ECB mode requires an initialization vector, that is used for different things depending on the mode (in CTR it's used to produce the keystream; in ...


0

The system you're describing sounds a lot like standard cookie based authentication/session management systems, in that you authenticate the user and then provide a session token to them which allows you to identify requests from that user for the duration of their session. Whilst you could implement this manually, I would recommend against it, as there are ...


2

The credentials may be shared for the whole network (eg. LDAP credentials), allowing access to the local computer, mail, remote access… Also note that Phishing OS credentials is very different than phishing a website. You don't go back to a computer and fill an Email prompt without even logging in (actually, I don't think many company users enter their ...


1

I think it is fine to have a web facing panel as long as: Its not guessable, for example, www.example.com/admin. U don't want notorious users to attempt brute-forcing for two reasons: Incase the brute-force succeeds. If u have an account lockout policy in place, which you should, u don't want to be locked out by notorious users. Use strong passwords ...


2

The system-attention-key is mostly an historical remnant from the youth days of the engineers who designed the SAK. These engineers, when they think about security, actually think about the times when they were dabbling in security, and that was when they were students. More precisely, when they were students in the 1990s. That last item is important: in the ...


0

For low value sites, username and password is ok. There are a lot of sites that are just not worth hacking into, and where the risk/cost of compromise to you is fairly minimal compared to the cost of securing it. For most sites though, you should require the use of HTTPS or VPN when doing administrative functions. There are now some SSL certificate ...


0

Lot of applications relies on a simple username/password combination. This is not the technique that you should worry about, but how you implement it. You need to make sure that passwords are strong enough not to be guessed. They should not be stored in plain-text in your database in case it gets compromised. Furthermore, you want to avoid interception of ...


0

I don't see the point in worrying about your scenario #3; that tactic will be just as successful as scenario #4: A botnet targeting many accounts trying one of many common passwords on each attempt. Imagine you have a million users, 10% of which randomly use one of the 1000 most common passwords (123456, password, letmein, ...). If a botnet tries ...


1

While this is an interesting idea, I would suggest keeping it normal as you have it but give users option for 2 factor authentication in their account settings. In this when a user successfully enters their credentials, they would be emailed a link to click / follow. Once followed their session would be started. You have to assume your clients are stupid, ...


6

There are a few benefits that persist in 2FA: A keylogger can't make use of my 2FA passwords for later. I can't share my 2FA with somebody on an ongoing basis. I'm more likely to know my 2FA credentials are compromised (e.g., because my token is missing) than somebody simply copying my sticky note hidden in my wallet. Somebody who phishes you will be have ...


1

I came up with the code below but it doesn't work That's because you are performing a CSRF attack, but in exercise 2.1 there is actually an anti-CSRF token preventing this. You have to exploit the XSS vulnerability here. I came up with a plan to use a cookie and set the token to 'abc'. So, when I come to login, i use the username and password that I ...


0

It is all about tolerance to risk. As you stated, a sufficiently strong password (and assuming no shortcomings on application of security, etc... which is a large leap of faith) means that cracking could take an unreasonably long amount of time (today at least). The question is how much risk are you willing to take? When we are talking about digital security ...



Top 50 recent answers are included