Live data from Hacker News

Show HN: Forgiva – Never saves your passwords but regenerates them

forgiva.com

51–60 of 98 posts

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#51

> To crack a password with 70 bit entropy on a MacBook Pro Early 2013 it will take ~6 million years to complete all combinations on Normal complexity. On Intermediate complexity it will take ~24 million years and on Advanced complexity it will take ~280 million years to reach all combinations at minimum. If you were cracking a password wouldn't it be significantly faster to use GPU(s) rather than CPUs [1]? If so, why…

It's just for giving an idea about hardness. Of course GPU(s) or/and parallel processing far more better than that. We will put results with clusters and GPUs soon.

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#52

> To crack a password with 70 bit entropy on a MacBook Pro Early 2013 it will take ~6 million years to complete all combinations on Normal complexity. On Intermediate complexity it will take ~24 million years and on Advanced complexity it will take ~280 million years to reach all combinations at minimum. If you were cracking a password wouldn't it be significantly faster to use GPU(s) rather than CPUs [1]? If so, why…

> If you were cracking a password wouldn't it be significantly faster to use GPU(s) rather than CPUs?

When you're dealing with time scales greater than a decade, probably not. The right answer is almost always to wait until future hardware is available that can crack the password significantly faster than our current CPUs and GPUs. Whether that's quantum computers or just faster iterations of the kind of stuff we've got now doesn't really matter...the time spent waiting for new hardware is insignificant compared to the time spent waiting for calculations on current hardware to complete.

But I agree that it's disingenuous to list numbers like that because they're meaningless and aren't at all the answer to the "How soon can my password be cracked?" question.

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#53

As I see it, the main benefit of deterministic password generation is the convenience of not needing a password database. Indeed, if the scheme is simple and/or portable enough (e.g., PBKDF2) you can implement it from scratch in a minute or two, depending on what software you have handy. The convenience breaks down as you need to maintain additional state: password rotation, site-specific password rules, etc. Forgiva…

>> Spamming the input with an array of whatever OpenSSL algorithms Ruby happens to make available, rather than using a memory hard KDF like scrypt, is a bad smell.

Sooner or later key-derivation schemes gets outdated and requires a better version as happened to bcrypt [1] and will happen to scrypt [2].

It is not "whatever OpenSSL provides" but just combining strong algorithms over to spread the "getting outdated" risks. Think like you are investing your money? Would you prefer betting on just one thing or spreading it over various different investment opportunities?

[1] http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html [2] http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#54
post #28

Earlier quoted context omitted.

>> What does this even mean? Again "theoretically" all encryption methods prone to brute-force attacks. And plus, encrypted storages indirectly reveals "encryption passwords" on succeeded attacks.

And if you go that path, "theoretically" an attacker might simply guess your password on the first try when attempting to log in as you, so password "storages" and "brute-force" has nothing to do it.

You are mistaken on one think: it is not just being it "theoretically" possible but likeliness -or hardness- of it.

If the possibility of an attacker guessing my password at first try is one in a billion -or trillion- chance, then we can say it pretty secure. But hacking a cloud with a possible zero-day flaw and cracking a password database is not that hard if we compare it with your example.

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#55
A couple thoughts that came to mind as I was reading it:

1) How is this safer than a standard password manager with TOTP-based 2FA? The second token, either produced by TOTP or something like a Yubikey, would guard against keyloggers, since the one-time code is useless after it has been entered.

2) How is the certificate generated, and what is it based on? Is the cert unique per device, or would I copy it to my other devices that need to access Forgiva ala a public key?

3) There are some typos and other grammatical weirdness on the page that suggests English is not the writer's first language. That's fine, but it looks unprofessional. I can make some proofreading suggestions if you feel inclined. I don't really believe in this product, but I'd prefer it to be judged on its technical integrity rather than the quality of its marketing, so I'd be happy to help polish it up.

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#56

Earlier quoted context omitted.

Theoretically stored passwords are not safe at all. Sooner or later they will get stolen if it is the case. Forgiva is actually big brother of kyle ( https://github.com/esurharun/kyle ) which has been at use for nearly 2 years and experienced and tested a lot. Yes, you are definitely right on that we should put roadmap on webpage. And no we are nor "nefarious" hackers neither junior NodeJS developers. :)

https://github.com/esurharun/kyle/blob/master/lib/kyle.rb#L1... ret += Constants::PASSWORD_CHARS[c % Constants::PASSWORD_CHARS.length] Looks like biased output. Also, what is this? (From https://github.com/sceptive/Forgiva ) algorithm forgiva-iterative-hashing Input: Value to hashed as DATA, Algorithm array AARRAY Ouput: Hashed input data final_value = DATA for each character C in DATA algorithm = AARRAY index of (C…

It generates underterministic way of calculation for a time-span of a successfull brute-force attack. Various hashing and encryption algorithms runs in different performance values. Thus, estimating for a CPU/GPU power or time range to attack Forgiva is more harder than other systems.

Every master-key generates a different time and processor cost as you see. So this makes estimations fail for all attacking sessions.

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#57
The Windows 64-bit installer is giving a bad signature even though its SHA256 installer hash appears to be correct.

It looks like they used SHA1 checks in the installer. I suspect the author doesn't realize that older Win installers that use SHA1 are blindly rejected by Win10 as a security measure (mostly because it's so feasible to game).

It is a very poor introduction to the application on the majority platform.

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#58

Your password will never be secure when you store it on someone else his disk or let someone else encrypt your password. Its not a matter of how, but when there will be a way to retreive those passwords by anything but you. And its not just that, everything you use your passwords for these days, is stored on some sort of storage in a cloudy architecture. Scattered all over the world in thousands of datacenters. You p…

You are right. Only after having reviewed the code for the OS (and before that reverse - engineered the BIOS firmware), recompiled it yourself and then reviewed & recompiled keepass can you state that you are safe. This is the recommended way to go for the standard user to have his passwords safely stored.

The alternative to trust a well - established company with your Tinder or gmail password is unthinkable.

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#59

A couple thoughts that came to mind as I was reading it: 1) How is this safer than a standard password manager with TOTP-based 2FA? The second token, either produced by TOTP or something like a Yubikey, would guard against keyloggers, since the one-time code is useless after it has been entered. 2) How is the certificate generated, and what is it based on? Is the cert unique per device, or would I copy it to my other…

>> 1) How is this safer than a standard password manager with TOTP-based 2FA? The second token, either produced by TOTP or something like a Yubikey, would guard against keyloggers, since the one-time code is useless after it has been entered.

No matter how many factors you are using, sooner-or-later you pass it with keyboards.And that step may be intercepted and you may think that you sent the second token to the other-side but failed.

I can provide you a special investigation of Sceptive to show how 2-factor-authentications has been bypassed by malwares targeting Eastern-Europe banks.

>> 2) How is the certificate generated, and what is it based on? Is the cert unique per device, or would I copy it to my other devices that need to access Forgiva ala a public key?

It is not unique per device. You can copy it to all devices you use no matter what.

>> 3) There are some typos and other grammatical weirdness on the page that suggests English is not the writer's first language. That's fine, but it looks unprofessional. I can make some proofreading suggestions if you feel inclined. I don't really believe in this product, but I'd prefer it to be judged on its technical integrity rather than the quality of its marketing, so I'd be happy to help polish it up.

It would be an excellent help, we are very unprofessional on language and marketing -as you well see-. Can you please send an e-mail to us at info@forgiva.com to tell us our mistakes?

Re: Show HN: Forgiva – Never saves your passwords but regenerates them

#60

As I see it, the main benefit of deterministic password generation is the convenience of not needing a password database. Indeed, if the scheme is simple and/or portable enough (e.g., PBKDF2) you can implement it from scratch in a minute or two, depending on what software you have handy. The convenience breaks down as you need to maintain additional state: password rotation, site-specific password rules, etc. Forgiva…

>> Spamming the input with an array of whatever OpenSSL algorithms Ruby happens to make available, rather than using a memory hard KDF like scrypt, is a bad smell. Sooner or later key-derivation schemes gets outdated and requires a better version as happened to bcrypt [1] and will happen to scrypt [2]. It is not "whatever OpenSSL provides" but just combining strong algorithms over to spread the "getting outdated" ris…

Not only did that not happen to bcrypt, but the whole point of bcrypt is that that doesn't happen: it's an adaptive hashing scheme, which means it comes with a dial you can turn to up the hardness as computers get faster.

I would be nervous about taking password storage advice from someone who thinks bcrypt "got outdated and requires a better version".

We had a Password Hashing Competition because people realized that password hashing and KDFs had become an important topic that hadn't received significant formal study. Similarly: we're having a CAESAR competition because people have recognized the importance of all-in-one authenticated encryption constructions. The existence of CAESAR, AEZ, NORX, &c doesn't mean that Poly1305-AES is "outdated and requires a better version".

Post reply on HN